Re: [mpls] Identifier Semantics [Re: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt]

[Dimitri.Papadimitriou@alcatel.be]

lou, all, see in-line




Lou Berger <lberger@labn.net>
22/06/2006 21:10
 
        To:     Rahul Aggarwal <rahul@juniper.net>
        cc:     fenner@research.att.com, mpls@ietf.org, 
rcallon@juniper.net, ccamp <ccamp@ops.ietf.org>
        Subject:        Re: [mpls] Identifier Semantics [Re: working group 
last call       on draft-ietf-mpls-rsvp-te-p2mp-05.txt]


> All,
>
> Here's one (but not the only) comment that was made off list.  Also 
> there were already several comments made on these points on the list.
>
> My comment still applies, and please consider this as an "objection" 
> to the proposed text:
> 
> At 01:20 PM 6/22/2006, Lou Berger wrote:
>>[...]
>>At 05:23 PM 6/20/2006, Rahul Aggarwal wrote:
>>>Hi All,
>>>
>>>Attached is draft-ietf-mpls-rsvp-te-p2mp-06.txt that incorporates 
changes
>>>to address Last call comments.
>>>
>>>Please let me know if you have any comments on *only the changes made 
to
>>>address LC comments* i.e. diff of v05 and v06 by this Friday.
>>>
>>>A brief summary of changes:
>>>
>>>1. Editorial changes requested by Benjamin Niven - see MPLS mailing 
list.
>>>2. Several editorial and non editorial changes requestd by Adrian 
Farrel -
>>>see MPLS mailing list for Adrian's comments and my response. There may 
be
>>>one or two open items here. Once Adrian looks at my response these 
should
>>>be resolved quickly.
>>>3. Several editorial and non-editorial changes requestd by JL - see 
MPLS
>>>mailing list for JL's comments and my response.
>>>4. Clarification of tunnel ID and extended Tunnel ID semantics as
>>>requested by Yakov Rekhter and follow on comments by Zafar Ali and 
George
>>>Swallow.
>
>The objection:
>
>>I don't have any issues with the changes mentioned by Zafer and 
>>George, but I didn't see closure on the issue debated by Adrian and 
>>Yakov.  Specifically on the issue of if extended tunnel ID had to 
>>equal the node ID of the sender.  I did see a position state, that I 
>>too agree with, i.e., that  it should be permitted and may be 
>>required in some environments (e.g., FRR) but may not be required in 
>>all environments so should be left as before.  Also, as I read the 
>>mails most were in favor of leaving tunnel ID as is, i.e., not 
>>requiring it to be set to zero.  This doesn't match what was done in 
>>this past rev.
>
>In summary, my position is:
>1) That the extended tunnel ID remain as defined in the previous 
>version, i.e., retain the semantics from rfc3209/rfc3473.  I think 
>adding a restriction for environments where FRR is used is 
>acceptable.  (This spec covers GMPLS and non-packet environments too!)
>2) That Tunnel ID remain as defined in previous version, i.e., retain 
>the semantics from rfc3209/rfc3473.
>
>The specifics of the text below is dependent on consensus on these 
points.

[dp] if there is no Tunnel ID (or a single fixed value for the Tunnel ID), 
there is no possibility to instantiate multiple trunks per destination 
(set of destinations)

now there is a more fundamental issue: what is the purpose of the initial 
comment, i think it is first to clarify  processing of Tunnel ID and 
Extended Tunnel ID but i don't think i have seen any specific issue in 
keeping usage of the Tunnel ID & Extended Tunnel ID per RFC 3209/3473

i am deeply concerned about having moving definition departing from base 
RSVP-TE on objects that are fundamental for the stability of the protocol

thanks,
- dimitri.