The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] [mpls] MPLS wg last call on re-spun bundling draft
At 08:09 AM 11/29/2004, Adrian Farrel wrote: >Hi, >Editorial comments... >The document is indicated as updating RFC3471. >Does it also update RFC3477? See section 2... > This section is equally applicable to the case of unnumbered > component links (see [LINK-BUNDLE]). Don't think so. Where do you see the update? >Ditto 3480 >Section 4.3 Duplicate paragraph... > With RSVP the choice of the component link is indicated by the sender > of the Path message by including the IF_ID RSVP_HOP object in the > Path message, as described in section 8 of [RFC3473]. With CR-LDP > the choice of the component link is indicated by the sender of the > REQUEST message by including the IF_ID TLV in the REQUEST message, as > described in section 8 of [RFC3472]. wow, that's cool. Thanks. >FWIW >gmpls-routing is now at a later revision. >Yakov wrote... >>- Section numbering will remain unchanged so as not to break any >>potentially existing references to the draft >Your choice. >The RFC Ed will fix this anyway as it is a strict rule. >Thus references will be broken if they use numbers (which they shouldn't >pre RFC) instead of names (which they should). > >Technical comments... >Yakov wrote... >>1. Scope of component identifiers is open to interpretation (i.e., node >>vs link) >>Issue 1: The -05 document states that all component link TLV types >> have Node/IP scope > >I think this is still ambiguous in the current revision. >It would not hurt to be exceptionally scrupulous about this definition. >Section 4... > Furthermore we restrict the identifiers that can be used to identify > component links such that they have node scope. >This does not appear to allow IP scope. >Section 4.1... > Component link identifiers MUST have node wide scope and MUST be > unique across both TE and component link identifiers. >Ditto okay, Here's what the next rev will say: section 4: Furthermore we restrict the identifiers that can be used to identify component links such that they are unique for a given node. section 4.1: Component link identifiers MUST be unique across both TE and component link identifiers on a particular node. This means that unnumbered identifiers have node wide scope, and that numbered identifiers have the same scope as IP addresses. >Yakov wrote... >>4. Lack of IPv6 support for types 3, 4, and 5. >>Issue 4: Based on the previous change, support of IPv6 unnumbered >> components is now tied to, and the same as, the support >> of IPv6 unnumber TE links. > >That's OK, but may be a tad ambiguous to some readers. >What is an IPv6 unnumbered TE link? >It appears to me that there is no distinction between IPv6 and IPv4 >unnumbered links. They are identified by a router ID (4 bytes) and a link >ID (4 bytes). There is nothing related to IPv4 or IPv6 there. >Not sure that you need to make any changes to the text, however (except >that the IESG may not understand this point and so might bounce the draft >asking where the IPv6 support is :-) >Yakov wrote... >>5. Ambiguity of when to use types 4 and 5 and when to use type 3. >>Issue 5: -05 allows, but recommend against use of types 4 and 5 >Wouldn't it be nice if the TLVs were under IANA control? They are. See http://www.iana.org/assignments/gmpls-sig-parameters >Then you could deprecate 4 and 5. Good point. This should go in an IANA considerations section. >Yakov wrote... >>6. No coverage of ERO and RRO implications >>Issue 6: EROs, RROs remain out of scope of bundling document >Good. I support this. >But do you propose to clarify PathErr/Notify reporting? >If you report the component link in a PathErr/Notify the ingress may not >be able to grok the context (especially if the component link is numbered). >Would you like to state that the PathErr/Notify MUST use to bundle ID? Not sure there is a real issue here. Components will either have IP or node scope. In the former case, the address should be meaning full. In the later case, the node ID should be meaning full and the TE link can be identified in the Error Address field. I guess we can add some clarifying text... >(I guess the same applies to ResvErr.) The information is already carried in the HOP object of a ResvErr. >I am concerned about the assumed symmetry in bidirecitonal cases. I know >we have agreed that a bidirectional LSP will always use the same TE link >in both directions, but we are clearly allowing different component links >to be used in each direction. OK. But what if the TE link is a bundle in >one direction and a single link in the other direction? I think we can >handle this just fine, but maybe we should say so? I don't have a strong opinion here. What specifically are you suggesting? Thanks for the comments, Lou >Thanks, >Adrian > >_______________________________________________ >mpls mailing list >mpls@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls
|
|