Subject: Re: [CCAMP] Question on RFC6107, Procedures for Dynamically Signaled Hierarchical Label Switched Paths

From: Alan Davey <[email-masked]>
Date: Wed, 2 Nov 2011 10:09:17 +0000

Hi Ramon

I think that this is a separate point to those in the errata.  

My view on your question is that the egress must signal its link endpoint identification for each IGP instance and therefore there must be N instances of the object in the Resv in your example.  Each instance of the object could be considered to be associated with a different IGP instance identifier even if the TLV is not actually present.  In the general case, the values of the other fields and TLVs in the LSP_TUNNEL_INTERFACE_ID objects may not be the same.  For example, the interface address could be different for each IGP instance.

Regards
Alan Davey

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ramon Casellas
Sent: 31 October 2011 13:58
To: [email-masked]
Subject: Re: [CCAMP] Question on RFC6107, Procedures for Dynamically Signaled Hierarchical Label Switched Paths

El 31/10/2011 14:20, Adrian Farrel escribió:
> Looks fine, but I would like to hear agreement from the WG.
>
> Thanks,
> Adrian
>
>> -----Original Message-----
>> From: Alan Davey [mailto:[email-masked]]
>> Original text:
>>     The TLV has meaning only in a Path message.  It SHOULD NOT be
>>     included in the LSP_TUNNEL_INTERFACE_ID object in a Resv message and
>>     MUST be ignored if found.
>>
>> Corrected text:
>>     The TLV has meaning only in a Path message.  At most one TLV
>>     MAY appear in a single LSP_TUNNEL_INTERFACE_ID object.
>>
>>     The TLV SHOULD NOT be included in the LSP_TUNNEL_INTERFACE_ID object
>>     in a Resv message and MUST be ignored if found.
Hi Adrian, Alan, all

I'm a bit confused about this part. If :
- several LSP_TUNNEL_INTERFACE_ID are used in the Path message to 
announce the same link in different instances (say N), and
- a TLV is used in each LSP_TUNNEL_INTERFACE_ID within such Path message 
(with the instance), and
- the TLVs SHOULD be suppressed in Resv,

do we end up with 1 or N identical LSP_TUNNEL_INTERFACE_ID in the Resv 
(assuming no other TLVs)?

It seems that they could be coalesced  into 1, in order not to be in 
contradiction with section 3.4 ("Each instance MUST have a different IGP
    Instance Identifier", which could be understood to preclude 
identical copies. but probably I am missing something)

So either there are N instances with the TLV (which it shouldn't by the 
above text but must according to 3.4) or 1 without TLV?. I would say the 
latter, but I would like your comments

R.

----------------------------------
Section 3.4 quote

    It is possible that an LSP will be used to offer capacity and
    connectivity to multiple other networks.  In this case, multiple
    instances of the LSP_TUNNEL_INTERFACE_ID object are permitted in the
    same Path and Resv messages.  Each instance MUST have a different IGP
    Instance Identifier.
_______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

---

From: Ramon Casellas <[email-masked]>
Date: Wed, 02 Nov 2011 11:22:41 +0100

> My view on your question is that the egress must signal its link endpoint identification for each IGP instance and therefore there must be N instances of the object in the Resv in your example.  Ea…

Fair enough, I guess I was wondering whether the text in sect 3.4 should 
be clarified, or it clearly means "Each instance MUST have a different 
IGP Instance Identifier if the TLV is present".
Thanks
R.

Section 3.4 "In this case, multiple (...) Each instance MUST have a different IGP Instance Identifier."

---

From: Lou Berger <[email-masked]>
Date: Wed, 02 Nov 2011 07:27:27 -0400

Adrian/Alan,

I think there are separable issues here that should be addressed
independently.

Item 2 below is easy, and clear cut.  It should result in an errata.

Item 1 is more problematic as an errata.  I agree with Adrian's
analysis: RFC 6107 states that advertisement of "multiple instances of
the LSP_TUNNEL_INTERFACE_ID object are permitted", but doesn't say it's
required or that multiple TLVs of the same type are not permitted.
Based on this, I think it's reasonable to have an errata that highlights
that a receiver should be prepared to receive both multiple
LSP_TUNNEL_INTERFACE_ID objects and multiple TLVs of the same time
within a single object. While it may be reasonable for an errata to
suggest reducing the number of options, I think changing behavior on the
wire really needs to be run through the normal working group process.

Lou

On 10/31/2011 9:20 AM, Adrian Farrel wrote:
>> Sent: 31 October 2011 11:41
>> To: Adrian Farrel Personal
>> Cc: [email-masked]
>> Subject: RE: [CCAMP] Question on RFC6107, Procedures for Dynamically Signaled
>> Hierarchical Label Switched Paths
>>
>> Hi Adrian
>>
>> Thank you for your response, and for spotting another erratum in RFC6107.  I
>> propose raising the following technical errata against the RFC, both in
> section 3.2.
>> Please let me know whether or not you agree.
>>
>> 1.  State that at most one Target IGP Identification TLV may appear in a
> single
>> LSP_TUNNEL_INTERFACE_ID object.
>>
>> Original text:
>> 2.  Section 3.2, change Resv message to Path message.
>>
>> Original text:
>>    If the P-flag in the Actions field in the LSP_TUNNEL_INTERFACE_ID
>>    object in a Resv message is set (i.e., one) indicating that the LSP
>>    is not to be advertised as a link, this TLV SHOULD NOT be present and
>>    MUST be ignored if encountered.
>>
>> Corrected text:
>>    If the P-flag in the Actions field in the LSP_TUNNEL_INTERFACE_ID
>>    object in a Path message is set (i.e., one) indicating that the LSP
>>    is not to be advertised as a link, this TLV SHOULD NOT be present and
>>    MUST be ignored if encountered.
>>
>> Regards
>> Alan Davey
>>
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of
>> Adrian Farrel
>> Sent: 28 October 2011 18:24
>> To: Alan Davey; [email-masked]
>> Hi Alan,
>> Nice to be made to read stuff because you come across typos. I think that
>> Section 3.2
>>
>>    If the P-flag in the Actions field in the LSP_TUNNEL_INTERFACE_ID
>>    object in a Resv message is set (i.e., one) indicating that the LSP
>>    is not to be advertised as a link, this TLV SHOULD NOT be present and
>>    MUST be ignored if encountered.
>>
>> s/Resv/Path/   !
>>
>> That merits an erratum if anyone can be bothered.
>>
>>> I have a question on RFC6107; is it permitted to have more than one
>>> Target IGP Identification TLV in a single LSP_TUNNEL_INTERFACE_ID object?
>>>
>>> I cannot find a definitive statement in the RFC as to whether or not
> multiple
>>> Target IGP Identification TLVs are permitted in a single object.
>>
>> Agreed. No such statement found.
>>
>>> However, I think that this should NOT be permitted.
>>>
>>> My thinking is as follows.
>>> - Section 3.4 states that "It is possible that an LSP will be used to offer
>>>   capacity and connectivity to multiple other networks.  In this case,
>>>   multiple instances of the LSP_TUNNEL_INTERFACE_ID object are
>>>   permitted in the same Path and Resv messages."
>>> - My reading of this is that if multiple Target IGP Identification TLVs
>>>   are required then they should each appear in a separate
>>>   LSP_TUNNEL_INTERFACE_ID object.
>>> - However, if multiple Target IGP Identification TLVs are permitted
>>>   in a single LSP_TUNNEL_INTERFACE_ID object then there are two
>>>   protocol constructs with the same meaning, which could lead to
>>>   interoperability problems.
>>> - Therefore RFC6107 should state that at most one Target IGP
>>>   Identification TLV may appear in a single LSP_TUNNEL_INTERFACE_ID
>>>   object, but I cannot find any such statement.
>>
>> i wouldn't object to imposing this limitation, but I don't see it as
>> particularly necessary: why would there be interop problems if both multiple
>> TLVs and multiple objects are allowed? Conservative on what you send, liberal
> on
>> what you receive. Since the RFC does not (currently) prohibit either option,
>> there would be no reason for an implementation to not be able to receive
> either.
>>
>> I don't read "are permitted" to mean "required"
>>
>> There would seem to be a (minor) saving of bits on the wire in the case that
>> multiple uses share the settings of the common part of the object. However,
>> since this is pretty unlikely:
>> 1. The chance of multiple TLVs being present is small
>> 2. The hardship of banning multiple TLVs is small
>>
>> This could probably (just about) qualify for an erratum. Really it is a
>> technical change, not a typographical fix, but we might squeeze it in as a one
>> line change.
>>
>> Cheers,
>> Adrian
>>
>>

---

From: Alan Davey <[email-masked]>
Date: Thu, 3 Nov 2011 11:12:50 +0000

Lou

Thank you for your response.  I agree on item 2.

On item 1, I think that the question is; has anyone implemented sending multiple IGP Instance TLVs in the same object.

If they have then we cannot raise an erratum.

If they have not then we have the chance to tighten the spec and reduce the chances of interoperability issues.

Regards
Alan

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: 02 November 2011 11:27
To: Aria - Adrian Farrel Personal
Cc: Alan Davey; [email-masked]
Subject: Re: [CCAMP] Question on RFC6107, Procedures for Dynamically Signaled Hierarchical Label Switched Paths

Adrian/Alan,

Lou

---

From: Lou Berger <[email-masked]>
Date: Thu, 03 Nov 2011 09:03:25 -0400

Alan,
	Erratum are to report technical errors or editorial changes.
I don't think an erratum can be used to change defined (or
under-defined) protocol behavior.  I think this takes a bis.

Certainly, if no one cares about the option you want to eliminate, this
will speed the bis process...

Lou

---

From: Alan Davey <[email-masked]>
Date: Mon, 7 Nov 2011 14:07:18 +0000

Lou

Thank you for clarifying the process.

I think that it would be overkill to create a bis of RFC6170 to clarify what is a fairly arcane corner of the protocol and therefore I will not pursue this.  However, I will raise an erratum for the issue spotted by Adrian.

Regards
Alan

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: 03 November 2011 13:03
To: Alan Davey
Cc: Aria - Adrian Farrel Personal; [email-masked]
Subject: Re: [CCAMP] Question on RFC6107, Procedures for Dynamically Signaled Hierarchical Label Switched Paths

Alan,

Lou