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

Ina,
Comments below. Thanks.
Cheers.

SA
--

> -----Original Message-----
> From: Ina Minei [mailto:ina@juniper.net]
> Sent: Friday, August 02, 2013 2:59 AM
> To: Santiago Alvarez (saalvare); mpls@ietf.org
> Subject: RE: LDP Color LSP - downstream unsolicited and on-demand
> 
> 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)

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. 

> 
> Thanks,
> 
> Ina
> 
> 
> -----Original Message-----
> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of
> Santiago Alvarez (saalvare)
> Sent: Friday, August 02, 2013 1:38 AM
> To: mpls@ietf.org
> Cc: Santiago Alvarez (saalvare)
> Subject: [mpls] LDP Color LSP - downstream unsolicited and on-demand
> 
> 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
> --
> 
> 
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
> 
> 
> 