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

["Dongjie (Jimmy)" <[e-mail]>]

Hi Lou, 

Thanks for your replies, and please see inline below:

> -----Original Message-----
> From: Lou Berger [mailto:[e-mail]]
> Sent: Friday, May 08, 2015 7:40 PM
> To: Dongjie (Jimmy); [e-mail]
> Cc: [e-mail]
> 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)" <[e-mail]> wrote:
> 
> > Hi Lou,
> >
> > Thanks a lot for your comments, and please see my replies inline:
> >
> > > -----Original Message-----
> > > From: Idr [mailto:[e-mail]] On Behalf Of Lou Berger
> > > Sent: Thursday, May 07, 2015 10:03 PM
> > > To: [e-mail]
> > > Cc: [e-mail]
> > > 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.

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. 

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.

That said, I'd agree that the ambiguity between RSVP and PCEP objects needs to be solved. 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".

Best regards,
Jie

> 
> Lou
> 
> > Best regards,
> > Jie
> >
> > > Lou
> > >
> > > On 5/7/2015 5:27 AM, [e-mail] 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
> > > > [e-mail]
> > > > 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
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/idr
> >
>