[mpls] RE: draft-ali-mpls-rsvp-te-s2l-name-01.txt

Hi Adrian- 

Please see reply in-line; sorry for the delay in replying.  

> -----Original Message-----
> From: Adrian Farrel [mailto:adrian@olddog.co.uk] 
> Sent: Sunday, July 15, 2007 8:46 AM
> To: Zafar Ali (zali); Robert Sawaya (rsawaya)
> Cc: mpls@lists.ietf.org
> Subject: draft-ali-mpls-rsvp-te-s2l-name-01.txt
> 
> Hi,
> 
> I don't see why you have defined a Flags field in this object 
> when you have not isolated any requirements for the flags.
> 
> If you want the object to be truly extensible, as you 
> suggest, then you should use TLVs. Without that, you are not 
> future-proof.
> 

This is an excellent comment. In the next version, we will define S2L
attribute using TLVs (rfc4420-style encoding). 

> Your draft should address scalability concerns for the 
> signaling protocol when per-leaf text strings (each of which 
> can be up to 255 bytes long : plus one byte of padding).
> 

While talking about P2MP scalability, we can divide scalability concerns
in following two buckets.  

1. Scalability aspects that are common for P2P and P2MP, e.g., # of
control plane states an LSR can have, etc. In this case, signaling
session names for 500 P2P LSPs is no different than signaling session
names for 500 S2Ls for a given P2MP LSP.  

2. Scalability aspects that are specific to P2MP, e.g., when a Path
message is used to signal one or more S2L sub-LSPs. Yes, I agree that
adding session name as a S2L attribute will increase the size of (such)
Path message. However, RFC 4875 supports fragmentation of Path state
information and an Ingress LSR can follow it (to ensure a Path message
remains within a single IP packet).    

> I remain completely unconvinced by the requirements expressed 
> in your draft. 
> Are you trying to identify control plane state or data plane 
> state? 

Control Plane. 

> Surely the P2MP LSP is identified by name, and the 
> branch is identified by name and the set of leaves reached 
> through that branch. Maybe you need to give an example of 
> usage by a management application.

With 500-to-1000 S2Ls for a given LSP are displayed or needs to be
filtered at an LSR console, working with destination IP address is not
user friendly. The same will apply to any management station when same/
similar data is transported to it. The reasons for S2L name is similar
to reasons for defining Session name for LSP. 

> 
> Cheers,
> Adrian 
> 

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls