Re: [mpls] working group adoption poll on draft-sitaraman-mpls-rsvp-shared-labels

[Vishnu Pavan Beeram <[e-mail]>]

Jie, Hi!

Thanks for the follow-up. Please see inline.

Regards,
-Pavan

On Fri, Nov 3, 2017 at 4:02 AM, Dongjie (Jimmy) <[e-mail]> wrote:

> Hi Pavan,
>
> Sorry for the delay in response. Please see inline:
>
> > -----Original Message-----
> > From: Vishnu Pavan Beeram [mailto:[e-mail]]
> > Sent: Monday, October 23, 2017 10:49 PM
> > To: Dongjie (Jimmy) <[e-mail]>
> > Cc: Loa Andersson <[e-mail]>; [e-mail]; <[e-mail]>
> > <[e-mail]>; [e-mail];
> > [e-mail]
> > Subject: Re: [mpls] working group adoption poll on,
> > draft-sitaraman-mpls-rsvp-shared-labels
> >
> > Jie, Hi!
> >
> > Thanks for the review and for the support. Please see inline for
> responses
> > (prefixed VPB).
> >
> > Regards,
> > -Pavan
> >
> > On Wed, Oct 18, 2017 at 11:18 AM, Dongjie (Jimmy) <[e-mail]>
> > wrote:
> > > Hi Loa,
> > >
> > > I've read this document and think it provides a useful function for
> reducing the
> > data plane state of RSVP-TE LSPs. Thus I support the adoption.
> > >
> > > I concur with Lou's concern about the TE bandwidth/tspec/rspec
> processing,
> > the impact of shared label on this needs to be specified.
> >
> > [VPB] Please see if my response to Lou adequately addresses your concern.
>
> The proposed text about the mapping between shared label and the bandwidth
> reservations would be a good start, and maybe the consequence of the
> reservation aggregation can also be described.
>

[Pavan] We will add the proposed text.


> > >
> > > I also have some concerns about the automatic delegation process
> described
> > in section 5.3, maybe I need to reread it, but it seems that in some
> cases the
> > mechanism may not result in an appropriate set of delegation nodes. And
> what
> > would happen if the ETLD value in the received PATH message is bigger
> than the
> > maximum number of labels this node can handle? It seems this case was not
> > covered in section 5.3.
> >
> > [VPB] Section 5.3.1 says --
> > "The ETLD MUST be decremented at each non-delegation transit hop by
> either 1
> > or some appropriate number based on the limitations at that hop."
> >
> > The "limitations at that hop" reference is not necessarily limited to the
> > "outbound limitation", it could include the "read limitation" as well.
> Consider a
> > transit hop that can read only 6 labels. If this hop receives an ETLD of
> 8 from the
> > previous-hop, then it could adjust the outgoing ETLD to 5 (thus ensuring
> that it
> > can never receive more label-stack-entries than it can read).
> Wi
> Thanks for the explanation. Yes both the send limitation and read
> limitation need to be taken into consideration. So in many cases decrement
> by some number other than 1 would be needed.
>
> [Pavan] Yes, agree. This is covered by the following statement in the
draft:

The ETLD MUST be decremented at each non-delegation transit hop by
either 1 or some appropriate number based on the limitations at that
hop.

Maybe it is worth mentioning that for transit nodes, the ETLD it sent is
> determined by both the received ETLD from previous hop and its read and
> send limitation in label processing?
>
[Pavan] The current text in the draft leaves sufficient room for this
behavior (and I'm aware of an implementation that does this already) and
also for the behavior where only the "imposition limitation" is taken into
account. That said, we can add some text to make this point clear.


>
> Another point is the ETLD is defined in HOP_ATTRIBUTES subobject, which
> means the transit node will add a new ETLD Attributes TLV for itself,
> rather than modifying the ETLD attribute it received from the previous hop.
> Some update to the description about the ETLD manipulation may be needed to
> reflect this.
>
[Pavan] Yes, as mentioned in the draft, ETLD is just another per-hop
attribute -- RFC7570 procedures come into play. A transit-hop that does not
support this functionality will not record the ETLD. We could possibly add
an Appendix detailing a "sample algorithm" in a later revision (if needed).


> I think all of the above can be done after the adoption.
>
[Pavan] Thanks!


> Best regards,
> Jie
>
> >
> > >
> > > It would be great if the above concerns could be considered either
> before or
> > after the adoption.
> > >
> > > Best regards,
> > > Jie
> > >
> > > -----Original Message-----
> > > From: mpls [mailto:[e-mail]] On Behalf Of Loa Andersson
> > > Sent: Saturday, October 14, 2017 11:20 PM
> > > To: [e-mail]
> > > Cc: <[e-mail]>;
> > > [e-mail]; [e-mail]
> > > Subject: [mpls] working group adoption poll on
> > > draft-sitaraman-mpls-rsvp-shared-labels
> > >
> > > Working Group,
> > >
> > > This is to start a two week poll on adopting
> > > draft-sitaraman-mpls-rsvp-shared-labels-02 as a MPLS working group
> > document.
> > >
> > > Please send your comments (support/not support) to the mpls working
> group
> > mailing list ([e-mail]). Please give a technical motivation for
> your
> > support/not support, especially if you think that the document should
> not be
> > adopted as a working group document.
> > >
> > > There are three IPR disclosures (though one disclosure seems to be an
> > > update) against this document.
> > >
> > > All the authors have stated on the MPLS wg mailing list that they are
> > > unaware of any other IPRs that those that has been disclosed
> > >
> > > The working group adoption poll ends October 29, 2017.
> > >
> > > /Loa
> > > mpls wg co-chair
> > > --
> > >
> > >
> > > Loa Andersson                        email: [e-mail]
> > > Senior MPLS Expert
> > > Huawei Technologies (consultant)     phone: [phone]
> > >
> > > _______________________________________________
> > > mpls mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/mpls
> > >
> > > _______________________________________________
> > > mpls mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/mpls
>