Subject: RE: I-D ACTION:draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt

From: "Zafar Ali \(zali\)" <[email-masked]>
Date: Thu, 9 Mar 2006 09:36:18 -0500

Hi Dimitri, 

Please see reply in-lined. 

Thanks

Regards... Zafar  

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of dimitri papadimitriou
> Sent: Thursday, March 09, 2006 6:07 AM
> To: [email-masked]
> Subject: Re: I-D ACTION:draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt
> 
> hi all, some comments on the problem statement of this doc:
> 
> "(2) How to identify the routing instance in which such an 
> advertisement should happen."
> 
> but by definition it is the same instance when speaking about 
> an FA (or are we not speaking about FA's only (?)

Correct, both FA and RA (Routing Adj). 

> the 
> previous paragraph seems to indicate this is not the case
> 
> "In order for the egress of an LSP to be able to advertise 
> the LSP as a TE link it needs to know that such an 
> advertisement is desirable, "
> 
> ok this is a trigger issue

Correct, to adv or not to adv. 

> 
> "and it also needs to know the TE Router ID of the ingress LSR.
> (Please recall that the Router ID of the other end of the 
> link is set in the Link-ID sub-TLV of the Link TLV of the TE 
> Opaque-LSA [RFC3630].)"
> 
> don't understand this; the Router ID is known and the TE 
> router ID is known as well (part of the TEDB) ... what's the 
> purpose of this new requirement (as there is no TE router ID 
> part of the corr. link TLV)
> 
> clarifications appreciated,

In the current signaling message, for numbered TE link it is NOT clear
where the Ingress/ Egress router-id-es are placed. Some implementation
use extended tunnel-id field for this but again this is not a must. So
please read the above as... 

"and (when LSP is signaled, Ingress/ Egress nodes ) also needs to know
the TE Router ID of the ingress LSR." 

Please also see related text in the ID related to how this help in
flooding.  

> 
> in general, if a clearer procedure for numbered FA signaling 
> could be devised that would be a good achievement, this said, 
> i am for inst. 
> unclear about these R and F bits ... where does numbered FA only adv.

A bi-directional LSP can be adv as an FA (only in MPLS TE topology) or
an RA (IP network) or both. These bits tells the Egress node on what
treatment is expected by the Ingress node. 
 
> per RFC4206 is reproduced here ? 

No, 

> what "adv. an FA in an IP network" 
> means ? 

The GMPLS bidirectional LSP is visible to IP topology for inclusion in
IP SPF. 

> why restrict adv. to MPLS-TE and IP networks only ? etc.

Can you please elaborate on this? 

> 
> imho, the issue of the trigger is part of a larger discussion 
> around FA policing ... in brief, providing a cleaner 
> procedure for numbered FA's is advisable but complexifying 
> procedures by incorporating policing related actions is not advisable
> 
> thanks,
> - dimitri.
> 
> [email-masked] wrote:
> 
> > A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> > 
> > 
> > 	Title		: Advertisement of hierarchical and 
> stitchable Label Switched Paths as Traffic Engineering Links
> > 	Author(s)	: K. Shiomoto, et al.
> > 	Filename	: draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt
> > 	Pages		: 17
> > 	Date		: 2006-3-7
> > 	
> > This document addresses topics related to hierarchical and stitched 
> > Generalized Multiprotocol Label Switching (GMPLS) Label 
> Switched Paths 
> > (LSPs).  It describes extensions to allow an egress to 
> identify that a 
> > bi-directional LSP will be used as a dynamically signaled 
> Forwarding 
> > Adjacency LSP (FA-LSP) or Routing Adjacency (RA). In addition, the 
> > document also addresses the issue of how to indicate that an LSP 
> > should be advertised as a traffic engineering (TE) link into a 
> > different instance of the IGP and how to identify the instance that 
> > should be used.
> > 
> > A URL for this Internet-Draft is:
> > 
> http://www.ietf.org/internet-drafts/draft-shiomoto-ccamp-lsp-hierarchy
> > -bis-01.txt
> > 
> > To remove yourself from the I-D Announcement list, send a 
> message to 
> > [email-masked] with the word unsubscribe in 
> the body of the message.
> > You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce
> > to change your subscription settings.
> > 
> > 
> > Internet-Drafts are also available by anonymous FTP. Login 
> with the username
> > "anonymous" and a password of your e-mail address. After logging in,
> > type "cd internet-drafts" and then
> > 	"get draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt".
> > 
> > A list of Internet-Drafts directories can be found in
> > http://www.ietf.org/shadow.html 
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > 
> > 
> > Internet-Drafts can also be obtained by e-mail.
> > 
> > Send a message to:
> > 	[email-masked].
> > In the body type:
> > 	"FILE 
> /internet-drafts/draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt".
> > 	
> > NOTE:	The mail server at ietf.org can return the document in
> > 	MIME-encoded form by using the "mpack" utility.  To use this
> > 	feature, insert the command "ENCODING mime" before the "FILE"
> > 	command.  To decode the response(s), you will need "munpack" or
> > 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> > 	exhibit different behavior, especially when dealing with
> > 	"multipart" MIME messages (i.e. documents which have been split
> > 	up into multiple messages), so check your local documentation on
> > 	how to manipulate these messages.
> > 		
> > 		
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
> > 
> > 
> > 
> --------------------------------------------------------------
> ----------
> > 
> > _______________________________________________
> > I-D-Announce mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/i-d-announce
>

---

From: [email-masked]
Date: Thu, 9 Mar 2006 16:19:26 +0100

hi

see my detailed comments in-line, the bottom line for me is that this 
document tries to solve four problems at the same time while each of them 
needs separate actions:

- the document tries to clarify the numbered FA LSP signaling (= RFC 4206 
bis)

- the document tries to extend mechanisms for stitchable LSP and 
hierarchical LSP

- the document tries to define policing and utilisation rules for these 
type of LSPs

- the document tries to extend the inheritance process not only to 
G/MPLS-TE control plane instance(s) but to IP networks

see in-line 

"Zafar Ali \(zali\)" <[email-masked]>
Sent by: [email-masked]
09/03/2006 15:36
 
        To:     <[email-masked]>, Dimitri 
PAPADIMITRIOU/BE/ALCATEL@ALCATEL, <[email-masked]>
        cc: 
        Subject:        RE: I-D 
ACTION:draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt

Hi Dimitri, 

Thanks

Regards... Zafar 

[dp] the document should clarify "RA signaling" need and issue this tries 
to solve, i think it means an LSP used for carrying both data and control 
traffic (in part. routing) but the question is what is expected from this 
indication

> the previous paragraph seems to indicate this is not the case
> 

[dp] yes, the question is what's the default behaviour when signaling an 
FA (since the doc clarifies when an LSP is an FA the point is what's a non 
advertized FA)

=> question is WHY is there something specific here for FAs (since the TE 
router ID is not part of the info in the link TLV)

=> and the question is WHY - link TLV does not need such information

=> why only in MPLS-TE topology (meaning why not TDM, LSC, etc.) ? 

=> the major question is that FAs where not meant to trigger any routing 
adjacency in IP networks, this document does introduce this now the main 
discussion point is not the bit in the TLV but that the inheritance 
mechanism is extended to IP network topology

No, 

> what "adv. an FA in an IP network" means ? 

=> this is a pure policing issue which is orthogonal to the signaling and 
adv. mechanisms

> >              Filename                : 
draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt