Subject: Re: [Idr] I-D Action: draft-ietf-idr-te-lsp-distribution-03.txt

From: Lou Berger <[email-masked]>
Date: Mon, 20 Jul 2015 19:28:50 +0200

I see I missed this message -- sorry.

On 5/13/2015 9:38 AM, Dongjie (Jimmy) wrote:
> Hi Lou, 
>
> Thanks for your replies, and please see inline below:
>
>> -----Original Message-----
>> From: Lou Berger [mailto:[email-masked]]
>> Sent: Friday, May 08, 2015 7:40 PM
>> To: Dongjie (Jimmy); [email-masked]
>> Cc: [email-masked]
>> Subject: RE: [Idr] I-D Action: draft-ietf-idr-te-lsp-distribution-03.txt
>>
>> Jie,
>>
>> See in line below.
>>
>>
>> On May 8, 2015 6:04:33 AM "Dongjie (Jimmy)" <[email-masked]> wrote:
>>
>>> Hi Lou,
>>>
>>> Thanks a lot for your comments, and please see my replies inline:
>>>
>>>> -----Original Message-----
>>>> From: Idr [mailto:[email-masked]] On Behalf Of Lou Berger
>>>> Sent: Thursday, May 07, 2015 10:03 PM
>>>> To: [email-masked]
>>>> Cc: [email-masked]
>>>> Subject: Re: [Idr] I-D Action:
>>>> draft-ietf-idr-te-lsp-distribution-03.txt
>>>>
>>>> Hi,
>>>>     I have a couple of questions on this draft:
>>>>
>>>>>    The 64-Bit 'Identifier' field is used to discriminate between
>>>>>    instances with different LSP technologies.  The default identifier
>>>>>    "0" identifies the instance for packet switched LSPs.
>>>>> A new
>>>>>    identifier TBD is used to identify the instance of optical layer
>>>>>    LSPs.
>>>> Doesn't it make more sense to just carry the values used in LSP
>>>> switching
>>> type
>>>> (See rfc3473/7074) for the non-zero  case?
>>> I agree with your point that this document could cover LSPs with
>>> different switching types. As for using the switching type values
>>> directly as identifier, we coauthors will discuss it and then feedback to you.
>>>
>> Sure, but unless there's a substantive justification, I really don't think we need
>> another name/number space for the same thing.
> What about we use another way to specify the LSP switching type: include the Generalized Label Request Object in the LSP State Information TLVs, as the switching type is one of the attributes of the LSP. The NLRI is used to specify the identifiers of the LSP.
So does this mean you'd drop the Identifier from the TE LSP NLRI?

>
> This would not require the assignment of several well-known values from the identifier registry. Our concern is that this identifier field and registry is generic for all BGP-LS NLRIs, and making reservations for some specific NLRIs may restrict the usage of such values. 
I've read this a few times and concluded I don't really understand what
you're proposing.  Can you try stating it a different way?  Perhaps just
send the changes that you'd make.
> If you agree with this method, we can add the corresponding specifications in next revision.

>>>>>   Currently the TE LSP Objects that can be carried in the LSP State TLV
>>>>>   include:
>>>> How do you distinguish between RSVP and PCEP objects?
>>> Good question. My understanding is for the same information, the
>>> format of RSVP and PCEP objects usually are compatible. In case there
>>> is some discrepancy, the current strategy is, for information which
>>> has corresponding RSVP object, the RSVP object is used, otherwise the
>>> PCEP object is used. Or do you have some suggestions about this?
>>>
>> There is collision/ambiguity so I'd use a different type or add a subtype.
> Our intention was to re-use the existing registries of LSP objects and avoid defining a new one. The advantage is every time some new object is defined in RSVP or PCEP, this BGP-LS specification does not need to be revised.

This makes sense
>
> That said, I'd agree that the ambiguity between RSVP and PCEP objects needs to be solved. 

yup, you currently have collision of values between protocols.

> One possible solution for this is to make the LSP State information TLVs hierarchical. We can define a set of top level TLVs, each one identifies the source/format of the information carried. For example, we can define a top-level sub-TLV for RSVP, which consists of the existing RSVP objects. Similarly, define another top level sub-TLV for PCEP, which carries the existing PCEP objects. We may also define a new top level sub-TLV for LSP information derived from other sources. This way we can solve the ambiguity without assigning new type values for every existing object. Hope this is in line with your proposal "add a subtype".
Yes, a mean a subtype = {RSVP|PCEP} not defining new values for all objects.

Lou
> Best regards,
> Jie
>
>> Lou
>>
>>> Best regards,
>>> Jie
>>>
>>>> Lou
>>>>
>>>> On 5/7/2015 5:27 AM, [email-masked] wrote:
>>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>>>>  This draft is a work item of the Inter-Domain Routing Working
>>>>> Group of the
>>>> IETF.
>>>>>         Title           : Distribution of MPLS Traffic Engineering (TE)
>> LSP
>>>> State using BGP
>>>>>         Authors         : Jie Dong
>>>>>                           Mach(Guoyi) Chen
>>>>>                           Hannes Gredler
>>>>>                           Stefano Previdi
>>>>>                           Jeff Tantsura
>>>>> 	Filename        : draft-ietf-idr-te-lsp-distribution-03.txt
>>>>> 	Pages           : 12
>>>>> 	Date            : 2015-05-07
>>>>>
>>>>> Abstract:
>>>>>    This document describes a mechanism to collect the Traffic
>>>>>    Engineering (TE) LSP information using BGP.  Such information can be
>>>>>    used by external components for path reoptimization, service
>>>>>    placement and network visualization.
>>>>>
>>>>>
>>>>>
>>>>> The IETF datatracker status page for this draft is:
>>>>> https://datatracker.ietf.org/doc/draft-ietf-idr-te-lsp-distributio
>>>>> n/
>>>>>
>>>>> There's also a htmlized version available at:
>>>>> https://tools.ietf.org/html/draft-ietf-idr-te-lsp-distribution-03
>>>>>
>>>>> A diff from the previous version is available at:
>>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-te-lsp-distributi
>>>>> on-0
>>>>> 3
>>>>>
>>>>>
>>>>> Please note that it may take a couple of minutes from the time of
>>>>> submission until the htmlized version and diff are available at
>>> tools.ietf.org.
>>>>> Internet-Drafts are also available by anonymous FTP at:
>>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>>
>>>>> _______________________________________________
>>>>> I-D-Announce mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce
>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html or
>>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>>>
>>>>
>>>> _______________________________________________
>>>> Idr mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/idr
>

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Tue, 21 Jul 2015 08:06:42 +0000

Hi Lou, 

Thanks for your response, and please see my replies inlined with [Jie]:

________________________________________
From: Lou Berger [[email-masked]]
Sent: Tuesday, July 21, 2015 1:28
To: Dongjie (Jimmy); [email-masked]
Cc: [email-masked]
Subject: Re: [Idr] I-D Action: draft-ietf-idr-te-lsp-distribution-03.txt

[Jie] Not exactly. As defined in draft-ietf-idr-ls-distribution, the identifier is used to identify the "routing universe" where the NLRI belongs. My suggestion is to not change the usage of this field. And if it is not applicable in some cases, it could be set to some default value.

[Jie] Let me try to explain this. The above sentence was to specify the reasons of not allocating some specific identifier values to represent switching types. As I said in the previous response, the values of the identifier field should be applicable to all NLRI types, so the definition and allocation of the identifier values are better not be restricted to only applicable to a specific NLRI type (e.g. the TE LSP NLRI). The proposed method is to reflect the LSP switchig type by including the Generalized Label Request Object in the LSP State TLV.

This makes sense

[Jie] Glad that we agreed on this.

[Jie] Good, so we are in sync on the solution to this issue. 

Best regards,
Jie

Lou

---

From: Lou Berger <[email-masked]>
Date: Thu, 23 Jul 2015 07:28:32 +0200

Jie,
See below.

On 7/21/2015 10:06 AM, Dongjie (Jimmy) wrote:
> ...
Ahh.  So the use of identifier in draft-ietf-idr-ls-distribution, which
basically identifies a routing instance, seems a bit different in your
document which says:

   The default identifier
   "0" identifies the instance for packet switched LSPs.  A new
   identifier TBD is used to identify the instance of optical layer
   LSPs.

So I read this as a technology identifier not an instance identifier. 
Perhaps this text needs to be revised?  Or am I still missing something?

> [Jie] Let me try to explain this. The above sentence was to specify the reasons of not allocating some specific identifier values to represent switching types. As I said in the previous response, the values of the identifier field should be applicable to all NLRI types, so the definition and allocation of the identifier values are better not be restricted to only applicable to a specific NLRI type (e.g. the TE LSP NLRI). 
My point was pretty simple: if the values match, and always should
match, a list of values already maintained by IANA, I think pointing to
that list rather than trying to create a new one makes the most sense. 
It sounds like you don't think there's a good list (registry) to leverage.

> The proposed method is to reflect the LSP switchig type by including the Generalized Label Request Object in the LSP State TLV.
This should work

>> If you agree with this method, we can add the corresponding specifications in next revision.
-- I'll keep an eye out for it in the next version.
> [Jie] Good, so we are in sync on the solution to this issue. 

Okay -- I'll also look for this change in the next version.

Thanks,
Lou

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 23 Jul 2015 08:47:33 +0000

Hi Jie, Lou, 

See one inline.

On 7/23/15, 7:28 AM, "Idr on behalf of Lou Berger" <[email-masked]
on behalf of [email-masked]> wrote:

>>> What about we use another way to specify the LSP switching type:
>>>include the Generalized Label Request Object in the LSP State
>>>Information TLVs, as the switching type is one of the attributes of the
>>>LSP. The NLRI is used to specify the identifiers of the LSP.
>> [Jie] Not exactly. As defined in draft-ietf-idr-ls-distribution, the
>>identifier is used to identify the "routing universe" where the NLRI
>>belongs. My suggestion is to not change the usage of this field. And if
>>it is not applicable in some cases, it could be set to some default
>>value.

This is from an older version of draft-ietf-idr-ls-distribution. I was the
routing directorate reviewer and asked that it be changed. You can just
take the definition from the latest version.

Thanks, 
Acee

>
>
>>> This would not require the assignment of several well-known values
>>>from the identifier registry. Our concern is that this identifier field
>>>and registry is generic for all BGP-LS NLRIs, and making reservations
>>>for some specific NLRIs may restrict the usage of such values.
>> [Jie] Let me try to explain this. The above sentence was to specify the
>>reasons of not allocating some specific identifier values to represent
>>switching types. As I said in the previous response, the values of the
>>identifier field should be applicable to all NLRI types, so the
>>definition and allocation of the identifier values are better not be
>>restricted to only applicable to a specific NLRI type (e.g. the TE LSP
>>NLRI). 
>> The proposed method is to reflect the LSP switchig type by including
>>the Generalized Label Request Object in the LSP State TLV.
>This should work
>
>>> Our intention was to re-use the existing registries of LSP objects and
>>>avoid defining a new one. The advantage is every time some new object
>>>is defined in RSVP or PCEP, this BGP-LS specification does not need to
>>>be revised.
>> This makes sense
>>
>>> One possible solution for this is to make the LSP State information
>>>TLVs hierarchical. We can define a set of top level TLVs, each one
>>>identifies the source/format of the information carried. For example,
>>>we can define a top-level sub-TLV for RSVP, which consists of the
>>>existing RSVP objects. Similarly, define another top level sub-TLV for
>>>PCEP, which carries the existing PCEP objects. We may also define a new
>>>top level sub-TLV for LSP information derived from other sources. This
>>>way we can solve the ambiguity without assigning new type values for
>>>every existing object. Hope this is in line with your proposal "add a
>>>subtype".

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 24 Jul 2015 08:47:01 +0000

Hi Acee, 

Thanks for pointing out this. Will check the definition in the latest verison. 

Best regards,
Jie
________________________________________
From: Acee Lindem (acee) [[email-masked]]
Sent: Thursday, July 23, 2015 16:47
To: Lou Berger; Dongjie (Jimmy); [email-masked]
Cc: [email-masked]
Subject: Re: [Idr] I-D Action: draft-ietf-idr-te-lsp-distribution-03.txt

Hi Jie, Lou,

See one inline.

Thanks,
Acee

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 24 Jul 2015 09:09:43 +0000

Hi Lou, 

Please see my replies inlined with [Jie#2]:

Best regards,
Jie
Sent: Thursday, July 23, 2015 13:28

Jie,
See below.

   The default identifier

[Jie#2]: Agree that the text about the default identifier needs to be revised. Will make the change in next revision. 

[Jie#2]: I totally agree with your idea of pointing to the existing registries. That's why I suggest to reuse the Generalized Label Request Object to reflect the switching type of the LSPs. And as you said, the identifier field is basically an instance identifier, so we will not use it as technology identifier.

This should work

[Jie#2]: Good we are agreed on this.

[Jie#2]: OK. We will make the change and submit a new revision after the meeting. 

[Jie#2]: Thanks. We will make the change and submit a new revision after the meeting. 

Thanks,
Lou