1 / 12

Draft-chakrabarti-idr-rfc4893-mod-00.txt

Draft-chakrabarti-idr-rfc4893-mod-00.txt. Samita Chakrabarti samitac@ipinfusion.com. What is it?. RFC 4893 clarification points A proposal for handling AS_PATH/AS4_PATH etc. Proposals for additional clarification texts A proposal for specifying a OPEN message notification.

xavier-dunn
Download Presentation

Draft-chakrabarti-idr-rfc4893-mod-00.txt

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Draft-chakrabarti-idr-rfc4893-mod-00.txt Samita Chakrabarti samitac@ipinfusion.com idr@IETF 71

  2. What is it? • RFC 4893 clarification points • A proposal for handling AS_PATH/AS4_PATH etc. • Proposals for additional clarification texts • A proposal for specifying a OPEN message notification idr@IETF 71

  3. What problem does it address ? • Lack of clarity in the specification • Unclear specifications = inconsistent implementations • Inconsistent implementations lead to Interoperability issues • Human error is unavoidable - diagnostic information can help • Scenarios for transition idr@IETF 71

  4. Change Requests • OPEN message • Section 4.2.1 and section 3 touches on “My AS number” field for AS_TRANS values on transmit only • New text for clarification • Provides text on handling “My AS Number” on SEND and RECEIVE of OPEN message • RECEIVE • When AS4 Capability is present, NEW BGP uses the AS number present in the Capability and ignores “My AS number” field in OPEN message • If NEW BGP receives an OPEN message without AS4 capability, then it must extract AS number from “My AS Number field”. If AS number value is AS_TRANS, it sends notification and closes connection idr@IETF 71

  5. Change Requests • RECEIVE (Continued…) • OLD BGP implementation ignores AS4 capability message and continues to process OPEN message according to RFC 4271 • SEND • RFC 4893 is clear on SEND side “My AS number” in OPEN • The new text uses RFC 4893 information idr@IETF 71

  6. Clarification Requests section 4.2.1 RFC 4893 states: "Note that peering between a NEW BGP speaker and an OLD one is possible only if the NEW BGP speaker has a 2-octet AS number. However, this document does not assume that an Autonomous System with NEW speakers has to have a globally unique 2-octet AS number - AS_TRANS could be used instead (even if a multiple Autonomous System would use it).“ R3 views R2 and R4 as part of same Autonomous domain; Some clarification or recommendation needed in the specification OLD (R3) OLD(R2) New(R4) AS=77777 New(R2) AS=66656 idr@IETF 71

  7. Clarification Requests Proposed Text: careful considerations are required such that it does not affect the routing path of the traffic due to some local policy on AS number at the OLD BGP speaker. During transition to NEW BGP speaker from an OLD BGP speaker, the above scenario should be avoided. Comment (Enke Chen): Reference to RFC 2270 could be provided as guidance idr@IETF 71

  8. A proposal for handling AS4 Attributes Example AS_PATH: • Always have AS_PATH and AS4_PATH from NBGP • Simple for implementation • No overloading of AS_PATH as in RFC4893 • No conversion of AS(4)_PATH, AS(4)_AGGREGATOR per update (RFC 4893) at NBGP routers • AS_PATH always contains 2-bytes values, AS4_PATH contains 4 bytes • Path length is computed from AS_PATH AS_PATH AS_PATH 23456, 500,200 500, 200 NBGP AS 500 OBGP AS 100 NBGP AS 66666 200 500 66666, 500 AS4_PATH AS4_PATH Updates idr@IETF 71

  9. A proposal for handling AS4 Attributes • Comments from Enke and Geoff • It is too late to consider new proposal now since implementations exist • Similar proposal was discussed before and discarded at the Wg • Conclusion • If it was discussed and analysed before then no point to bring up now idr@IETF 71

  10. A proposal for Notification • Human error do happens but diagnostic info helps • Although OLD BGPs should not use AS_TRANS as its AS number, but it has been used in customer’s network • Example of problem: OPEN without Capability and AS 23456 NBGP OBGP Proposal : Notification Error Code=2, Sub-code=2 (from RFC 4271) AS 23456 (Human error) idr@IETF 71

  11. Transition Cases (will be in next revision of the draft) • It is helpful if the specification points out different scenarios when special care is needed • For example : • Possible ambiguity in PATH origin determination at OLD BGP <2,3, 23456> • AS Override at the Provider Edge (Loop detected from AS4_PATH at CE) • PE routers in provider’s network must be converted to NBGP before CEs <200, 23456> <200,200> AS_PATH Loop detected PE2 (OLD) PE1(OLD) AS 200 VPN Site AS 77777 <77777> <77777> AS4_PATH VPN Site AS 77777 Acknowledgement: Satish Vardwarajula from Cisco Systems for AS Override transition issue idr@IETF 71

  12. Conclusion • Requesting Wg to adopt the proposals for clarifications and changes • Clear specification is very important for consistent and interoperable implementations toward a smooth transition to AS 4byte architecture • Comments? idr@IETF 71

More Related