Subject: [mpls] LDP Color LSP - downstream unsolicited and on-demand

From: "Santiago Alvarez (saalvare)" <[email-masked]>
Date: Fri, 2 Aug 2013 08:38:01 +0000

If I understood the question correctly, Ina asked why draft-alvarez-mpls-ldp-color-lsp-00 was only considering downstream unsolicited label allocation.  As mentioned on the mic, draft focuses on downstream label allocation, both unsolicited and on-demand.  Here's a snippet from the current doc:

" An egress LSR MAY include the Color List TLV in a Label Mapping
   Message if using Downstream Unsolicited mode.  An LSR may include the
   TLV in Label Request Messages if using Downstream on Demand mode.   "

Any further feedback appreciated. Thanks.

SA
--

---

From: Ina Minei <[email-masked]>
Date: Fri, 2 Aug 2013 09:59:22 +0000

Thank you for pointing out the text. 

A few questions on the draft:
- can you explain how the egress would know the colors it should advertise? (I am assuming you are assuming additional information from a different protocol, it would be good for the document to explicitly state this is the case and provide a use case)
- What kind of guarantees can the head end have regarding the path established, given that it has no indication whether all routers in the path support color matches or were able to select a path conforming to the colors (basically only part of the path conforms to colors) and how does this relate to the use cases solved. To give an extreme example, if c1 is "low latency" and c2 is "high latency", the egress signals for C1 but at node X only color c2 is available, given the requirement in section 5 for "at least one default path", what can be said of the resulting path at the head end (apart from the fact that a path exists). Does this mean that the default path has to be defined per color?
- the document does not specify the lsping processing rules, in particular at nodes where a particular color does not exist. Can you explain?

Thanks,

Ina 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Santiago Alvarez (saalvare)
Sent: Friday, August 02, 2013 1:38 AM
To: [email-masked]
Cc: Santiago Alvarez (saalvare)
Subject: [mpls] LDP Color LSP - downstream unsolicited and on-demand

SA
--

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

---

From: "Santiago Alvarez (saalvare)" <[email-masked]>
Date: Tue, 6 Aug 2013 15:53:06 +0000

Ina,
Comments below. Thanks.
Cheers.

SA
--

> From: Ina Minei [mailto:[email-masked]]
> Sent: Friday, August 02, 2013 2:59 AM
> To: Santiago Alvarez (saalvare); [email-masked]
> Subject: RE: LDP Color LSP - downstream unsolicited and on-demand
> 
> - can you explain how the egress would know the colors it should
> advertise? (I am assuming you are assuming additional information from
> a different protocol, it would be good for the document to explicitly
> state this is the case and provide a use case)

How an egress decides what colors to signal interest for is currently out of scope.  If you feel it should be otherwise, I'd be interested in hearing your views.

> - What kind of guarantees can the head end have regarding the path
> established, given that it has no indication whether all routers in the
> path support color matches or were able to select a path conforming to
> the colors (basically only part of the path conforms to colors) and how
> does this relate to the use cases solved. 

Using the terminology in section 3, the color LSR is the device responsible for initiating the advertisement of label mappings with an explicit color id.  If an ingress LSR receives such mapping, it can tell that there's at least one color LSR between itself and the egress LSR with a matching path, plus the LSRs between itself and the color LSR are capable of signaling color LSPs.

> To give an extreme example,
> if c1 is "low latency" and c2 is "high latency", the egress signals for
> C1 but at node X only color c2 is available, given the requirement in
> section 5 for "at least one default path", what can be said of the
> resulting path at the head end (apart from the fact that a path
> exists). Does this mean that the default path has to be defined per
> color?

If X is a color LSR and only has a C2 path and no default, the ingress LSR would receive no path to the destination prefix.

> - the document does not specify the lsping processing rules, in
> particular at nodes where a particular color does not exist. Can you
> explain?

I believe there are some additional LSP Ping details that we need to define in a later revision. 
 
> If I understood the question correctly, Ina asked why draft-alvarez-
> mpls-ldp-color-lsp-00 was only considering downstream unsolicited label
> allocation.  As mentioned on the mic, draft focuses on downstream label
> allocation, both unsolicited and on-demand.  Here's a snippet from the
> current doc:
>

---

From: Ina Minei <[email-masked]>
Date: Tue, 6 Aug 2013 23:20:14 +0000

Santiago, 

Please see inline. 

### I agree it is out of scope, but the draft should say so explicitly. The current text says:
"Egress LSR:
      May signal interest in particular colors towards upstream LSRs in
      order to influence the signaling behavior of color LSRs."
You may want to add that how the egress determines the colors it is interested in, and whether or not additional protocols are necessary, is outside the scope of this document. 

### It might also be very good to add a motivation/use cases section, which may further clarify the use (right now there is one paragraph only, in the introduction section). I find this paragraph (starting with "A sample deployment scenario") a bit confusing, since it implies that the characteristics of the path are not necessarily end to end, but apply to just a part of the path (the text "implement a forwarding preference for low latency or high bandwidth at the downstream P device"). Most of my comments below treat color as a characteristic of the link and assume it has to exist for all links in the path. It would really help to clarify these assumptions and use cases up front. 

> established, given that it has no indication whether all routers in 
> the path support color matches or were able to select a path 
> conforming to the colors (basically only part of the path conforms to 
> colors) and how does this relate to the use cases solved.

Using the terminology in section 3, the color LSR is the device responsible for initiating the advertisement of label mappings with an explicit color id.  If an ingress LSR receives such mapping, it can tell that there's at least one color LSR between itself and the egress LSR with a matching path, plus the LSRs between itself and the color LSR are capable of signaling color LSPs.
### see my comment above.

### I don't understand why this would be the case. Section 5 says: 
" At least one path
   MUST be defined as the "default" path.  This path SHOULD be used as a
   second best match in the absence of an exact color match." 
So in this case, at node X the path with color C2 MUST also be the default, no? I am confused about the specification, I'm sure I'm missing something in the operation (and I mean this in a constructive way, hoping this discussion will help make the draft a bit clearer). I think the main difference in how I am thinking of it and how the draft is written is that the draft seems to focus on use cases where there is a choice at some mid-point, and I am thinking of use cases where all links must comply to the color. 

### Final question - the draft assumes ordered control, correct? You may want to spell this out explicitly as well. 

 
> mpls-ldp-color-lsp-00 was only considering downstream unsolicited 
> label allocation.  As mentioned on the mic, draft focuses on 
> downstream label allocation, both unsolicited and on-demand.  Here's a 
> snippet from the current doc:
>

---

From: "Santiago Alvarez (saalvare)" <[email-masked]>
Date: Thu, 8 Aug 2013 17:10:42 +0000

Hi Ina,

Thanks a lot for the feedback. Some comments below.

> Sent: Tuesday, August 06, 2013 4:20 PM
> How an egress decides what colors to signal interest for is currently
> out of scope.  If you feel it should be otherwise, I'd be interested in
> hearing your views.
> 
> You may want to add that how the egress determines the colors it is
> interested in, and whether or not additional protocols are necessary,
> is outside the scope of this document.
> 

Point taken.

> ### It might also be very good to add a motivation/use cases section,
> which may further clarify the use (right now there is one paragraph
> only, in the introduction section). I find this paragraph (starting
> with "A sample deployment scenario") a bit confusing, since it implies
> that the characteristics of the path are not necessarily end to end,
> but apply to just a part of the path (the text "implement a forwarding
> preference for low latency or high bandwidth at the downstream P
> device"). Most of my comments below treat color as a characteristic of
> the link and assume it has to exist for all links in the path. It would
> really help to clarify these assumptions and use cases up front.
> 

Point taken.

> Using the terminology in section 3, the color LSR is the device
> responsible for initiating the advertisement of label mappings with an
> explicit color id.  If an ingress LSR receives such mapping, it can
> tell that there's at least one color LSR between itself and the egress
> LSR with a matching path, plus the LSRs between itself and the color
> LSR are capable of signaling color LSPs.
> If X is a color LSR and only has a C2 path and no default, the ingress
> LSR would receive no path to the destination prefix.
> 
> So in this case, at node X the path with color C2 MUST also be the
> default, no? I am confused about the specification, I'm sure I'm
> missing something in the operation (and I mean this in a constructive
> way, hoping this discussion will help make the draft a bit clearer). I
> think the main difference in how I am thinking of it and how the draft
> is written is that the draft seems to focus on use cases where there is
> a choice at some mid-point, and I am thinking of use cases where all
> links must comply to the color.
> 

You accurately introduced it as an extreme example. The way I read your text was a scenario where the default path wasn't operational.  We'll look into adding some text around the availability of the default path.

Also, we're addressing use cases where there's a forwarding choice at some mid-point.  That's certainly one scenario.  Extensions should ultimately address scenarios with multiple (or ultimately all) links/paths complying to a color.

> ### Final question - the draft assumes ordered control, correct? You
> may want to spell this out explicitly as well.
> 

Detailing the label mapping procedures is part of the next steps.
Thanks again.