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

[Dimitri.Papadimitriou@alcatel.be]

hi zafar


Hi Dimitri, 

Please see reply in-line. 

Thanks

Regards... Zafar 

> -----Original Message-----
> From: Dimitri.Papadimitriou@alcatel.be 
> [mailto:Dimitri.Papadimitriou@alcatel.be] 
> Sent: Thursday, March 09, 2006 10:19 AM
> To: Zafar Ali (zali)
> Cc: ccamp@ops.ietf.org; dpapadimitriou@psg.com
> Subject: RE: I-D ACTION:draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt
> 
> 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 

What you are referring as "policy" is the Ingress node's intended
treatment of the bi-directional LSP. Noticed that the assumption is that
the LSP-es are dynamically signaled and flooded to either IP, MPLS or
both networks. Since these LSP-es are dynamically signaled, we cannot
apply a config at the Egress node. We do all that today- but with
configuration knobs at the Egress node. 

=> but this part of a larger discussion than just processing of the 
signaling for numbered FAs, as an example why not signal the metric for 
the the FA link (instead of using the default rule ?), etc. this needs to 
be boiled down to the needs in terms of FA operations 

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

I am not sure how you deduced that. 

=> you state it in the above reply "flooded to either IP, MPLS or both 
networks" ... so not difficult to deduce ;-)

=> what's more important to me is your problem statement is initially to 
improve signaling of numbered FA LSPs as indicated in the backward 
compatibility section "Indeed it was the attempt to implement numbered FAs 
that gave rise to the work on this document." 

=> i am not saying that the other points should not be discussed but they 
should be done in a much structured way (do things right) ... provide a 
document that solves one issue but introduces others does not fall in this 
category

=> see in-line

> > 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). 
> 
> [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
> 

We can clearify this in the next revision. But in summary, when an LSP
is signalled as an RA, the Ingress and Egress nodes brings up IGP
Adjacency on top of it and flood it to the IP network. The same LSP can
independently be also flooded into MPLS network (if FA bit is set). 

=> "flooded to the IP network" what do you mean in the control plane 
topology ?

> > 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. 
> 
> [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)
> 

Often LSP-es are created for providing a short-cut for IP traffic
between the Ingress and Egress nodes. These LSP-es are NOT advertsied to
the network (I.e., are NOT FA-es, and of course not RA-es). When neither
FA nor RA bits are set, the LSP is NOT flooded at all. This is a non-FA
case. 

=> and so why does it has to be considered in this document ?

If the proposed extensions are NOT used, the default is "TO FLOOD" any
signaled LSP, as FA-LSP. This applies to both uni and bi-directional LSP
(but there is no issue when LSP is uni-directional, as Egress may still
decide NOT to flood it). 

=> nope, for unnumbered FA (bi-dir) LSP this is not the case

> > "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... 
> 
> => 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 (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. 
> 
> => and the question is WHY - link TLV does not need such information
> 
> > 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. 
> 
> => 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
> 

BTW there are deployments where uni-directional packet LSP-es are
advertised into IP topology (without establishing IGP adj over
unidirectional LSP-es, of course). So I am not sure what is new here? 

=> you are not specific enough in what you mean by the "IP topology" 
within the GMPLS context for me to comment on your statement

=> but more generally one way around either nothing is needed because once 
setup IP adj. are brought up (nothing new here, and nothing specific to be 
signaled) or you want to link the signaling operation such that the IGP 
instance triggers the adjacency ... my point is that you should first 
describe what the purpose of this instead of discussing the extension and 
then see what to do with it

> > 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? 
> 
> => this is a pure policing issue which is orthogonal to the 
> signaling and adv. Mechanisms

Please see my earlier comment about policy. 

> 
> > 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.
> > 
> > Internet-Drafts@ietf.org 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
> > > i-d-announce-request@ietf.org 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:
> > >              mailserv@ietf.org.
> > > 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
> > > I-D-Announce@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/i-d-announce
> > 
> 
>