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

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 29 Nov 2004 13:09:14 +0000

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

From: Lou Berger <[email-masked]>
Date: Mon, 29 Nov 2004 10:03:46 -0500

>  component links (see [LINK-BUNDLE]).

Don't think so.  Where do you see the update?

>  described in section 8 of [RFC3472].

wow, that's cool.  Thanks.

>Yakov wrote...
>>- Section numbering will remain unchanged so as not to break any 
>>potentially existing references to the draft
>Your choice.
>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...

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.

>>          components is now tied to, and the same as, the support 
>> of         IPv6 unnumber TE links.
>
>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...

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.

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

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