Subject: Re: [mpls] Comments on draft-ravisingh-mpls-el-for-seamless-mpls

From: Ravi Singh <[email-masked]>
Date: Fri, 11 Jul 2014 17:20:52 +0000

Hi Nobo
We have a new version of this draft:
	http://tools.ietf.org/html/draft-ravisingh-mpls-el-for-seamless-mpls-02

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Nobo Akiya (nobo)
> Sent: Thursday, November 07, 2013 12:23 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [mpls] Comments on draft-ravisingh-mpls-el-for-seamless-mpls
> 
> Hi Ravi, Yimin,
> 
> I have couple of comments.
> 
> 1. Stitched LSP - Proposed really offers optimization in stitched
> scenario.
> 
> a. Allows EL usage for even wider than just EL capable segments.
> b. Potentially speeds data traversal over stitched LSP as number of
> times ELI/EL popped/pushed are reduced.
> 
> Document sort of eludes to this, but I think it'll be beneficial to
> state that things will work as is (RFC6790), but proposal can be used
> as optimization.

The optimization aspect has been called out in the latest version.

> 2. Hierarchical LSP
> 
> >   B. Preventing multiple (ELI+EL) pairs underneath a given forwarding
> >       label in the stack:
> 
> I highly support above statement. Having multiple ELs in the stack
> will, yet again, cause more changes required in LSP traceroute wrt
> multipath information handling, and requires even more complex
> computation by initiator to traverse ECMP paths.

Great that we are in agreement.
Ravi

> -Nobo
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: Ravi Singh <[email-masked]>
Date: Fri, 11 Jul 2014 17:26:46 +0000

Hi Curtis
You've had comments on our usage of the term stitching in this draft.
We've clarified the same (in the latest version) and now instead of referring to the use-case as being "stitching" (as implied in the GMPLS case), we now refer to it as concatenation of LSPs.
Please refer the latest version and let me know if there are any further comments...
Thanks
Ravi

> From: Ravi Singh [mailto:[email-masked]]
> Sent: Friday, July 11, 2014 10:21 AM
> To: Nobo Akiya (nobo); draft-ravisingh-mpls-el-for-seamless-
> [email-masked]
> Cc: [email-masked]
> Subject: RE: Comments on draft-ravisingh-mpls-el-for-seamless-mpls
> 
> Hi Nobo

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Thu, 17 Jul 2014 02:24:06 +0000

Hi Ravi, et al,

[comment 1]
The document seems to be describing two different topics.
1. Data plane behavior regarding ELI/EL with stitched and/or hierarchical LSPs.
2. How to extend EL usage wider than actual capabilities of involved LSRs.

I agree that the two topics are rather related, but I find (1) to be a very useful information to vendors and (2) to be an optimization.
Is there any particular reason why the two topics cannot be broken up into two separate documents? That may result in much clearer documents.

[comment 2]
>From what I understand of the data plane behaviors, they boil down to following 4 things.

Behavior for an ingress LSR programmed to push [transport label(s), ELI, EL]:
a. The LSR SHOULD NOT push [ELI, EL] if the label stack already contain [ELI, EL], and SHOULD only push [transport label(s)].
b. If the LSR popping N transport labels includes popping of [ELI, EL], the LSR MAY reuse the popped [EL] value when needing to push [ELI, EL].
c. If the LSR popping N transport labels expose [ELI, EL] as top labels, the LSR MAY preserve the exposed [ELI, EL] in the label stack and only push [transport label(s)].

Behavior for an ingress LSR of ELC-not-capable LSP:
d. The LSR MUST ensure [ELI, EL] do not immediately follow label(s) pushed or swapped by the LSR.

Note, in the document, (a) is described as a procedure if [ELI, EL] are found under the top label only, but I don't think we need to make such restriction. Section 4.3. does is likely the reason why you restricted this to the top label only, but I prefer that this rule be kept simple and not restricted.  If you really want to ensure that [ELI, EL] appears near the top, then additional rule will do the job.

a-variant: The LSR SHOULD NOT push [ELI, EL] if the label stack already contain [ELI, EL], and SHOULD only push [transport label(s)]. The LSR MAY still push [transport label(s), ELI, EL] if [ELI, EL] found is deep in the label stack.

Do above (a-d), more or less, align with data plane rules you have in mind?

[comment 3 (nitpick)]

[snip from draft-ravisingh-mpls-el-for-seamless-mpls-02]

3. Key attributes of the entropy label solution: Summary from [EL-RFC]
[...]
     - Transport-label-POPing router POPs (ELI+EL) PHR/egress of the
       LSP is responsible for POPing off the (ELI+EL) after it has
       been exposed as the top label on the packet due to POPing the
       transport label. The removal of the (ELI+EL) is done either
       when the ELI is the top label; or when the ELI is next label
       below the top label being POPed.

It's a bit of a nitpick, but above is probably not an accurate reflection of RFC6790 regarding Penultimate Hop LSR behavior, as RFC6790 states:

[snip from RFC6790]

4.4.  Penultimate Hop LSR

   No change is needed at penultimate hop LSRs.  However, a PHP LSR that
   recognizes the ELI MAY choose to pop the ELI and following label
   (which should be an entropy label) in addition to popping the tunnel
   label, provided that doing so doesn't diminish its ability to load
   balance on the next hop.

Thanks!

-Nobo

> Sent: Friday, July 11, 2014 1:21 PM
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> > Of Nobo Akiya (nobo)

---

From: Ravi Singh <[email-masked]>
Date: Tue, 22 Jul 2014 14:30:59 +0000

Hi Nobo
Please see inline for [<RS>].

> From: Nobo Akiya (nobo) [mailto:[email-masked]]
> Sent: Wednesday, July 16, 2014 7:24 PM
> To: Ravi Singh; [email-masked]
> Cc: [email-masked]
> I agree that the two topics are rather related, but I find (1) to be a very useful
> information to vendors and (2) to be an optimization.
> Is there any particular reason why the two topics cannot be broken up into two
> separate documents? That may result in much clearer document

[<RS>] 	
I tend to think that 2 (being use-cases) is the reason that 1 is even worth being discussed.
That was the intent of having a single document for those. 
> a. The LSR SHOULD NOT push [ELI, EL] if the label stack already contain [ELI,
> EL], and SHOULD only push [transport label(s)].
> b. If the LSR popping N transport labels includes popping of [ELI, EL], the LSR
> MAY reuse the popped [EL] value when needing to push [ELI, EL].
> c. If the LSR popping N transport labels expose [ELI, EL] as top labels, the LSR
> MAY preserve the exposed [ELI, EL] in the label stack and only push [transport
> label(s)].
> 
> Note, in the document, (a) is described as a procedure if [ELI, EL] are found
> under the top label only, but I don't think we need to make such restriction.

[<RS>] I did not intend for this restriction to be there. 
Could you point to the specific language that makes you infer the above?

> Section 4.3. does is likely the reason why you restricted this to the top label
> only, but I prefer that this rule be kept simple and not restricted.  If you really
> want to ensure that [ELI, EL] appears near the top, then additional rule will do
> the job.
> 
> a-variant: The LSR SHOULD NOT push [ELI, EL] if the label stack already contain
> [ELI, EL], and SHOULD only push [transport label(s)]. The LSR MAY still push
> [transport label(s), ELI, EL] if [ELI, EL] found is deep in the label stack.
> 

[<RS>]  a & c do and are already there in the doc. 
I do not intend for b/d to be included in the doc. 
Could you point to specific reasons for considering b/d?

> 3. Key attributes of the entropy label solution: Summary from [EL-RFC] [...]
> It's a bit of a nitpick, but above is probably not an accurate reflection of
> RFC6790 regarding Penultimate Hop LSR behavior, as RFC6790 states:
> 
> [snip from RFC6790]
> 
> 4.4.  Penultimate Hop LSR
> 

[<RS>]  I don't see the above two blocks to be inconsistent.
Could you be more specific?
Thanks
Ravi

> > > Subject: [mpls] Comments on
> > > draft-ravisingh-mpls-el-for-seamless-mpls
> > >
> > > Hi Ravi, Yimin,
> > >
> > > state that things will work as is (RFC6790), but proposal can be
> > > used as optimization.
> >