Re: [mpls] MPLS wg last call on re-spun bundling draft

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]).
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]. 

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 

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?
Then you could deprecate 4 and 5. 

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?
(I guess the same applies to 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? 

Thanks,
Adrian 

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls