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

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

• Samita Chakrabarti
• samitac_at_ipinfusion.com

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

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

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

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

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) AS77777
New(R2) AS66656
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

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
500, 200
23456, 500,200
NBGP AS 500
NBGP AS 66666
OBGP AS 100
200
500
66666, 500
AS4_PATH
AS4_PATH
Updates
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

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 customers
  network
• Example of problem

OPEN without Capability and AS 23456
NBGP
OBGP
Proposal Notification Error Code2,
Sub-code2 (from RFC 4271)
AS 23456 (Human error)
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 lt2,3, 23456gt
• AS Override at the Provider Edge (Loop detected
  from AS4_PATH at CE)
• PE routers in providers network must be
  converted to NBGP before CEs

lt200, 23456gt
lt200,200gt AS_PATH
Loop detected
PE2 (OLD)
PE1(OLD)
AS 200
VPN Site AS 77777
lt77777gt
lt77777gt AS4_PATH
VPN Site AS 77777
Acknowledgement Satish Vardwarajula from Cisco
Systems for AS Override transition issue
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?