'[mpls] Comments to draft-tsaad-mpls-rsvpte-bidir-lsp-fastreroute'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mpls
Subject:    [mpls] Comments to draft-tsaad-mpls-rsvpte-bidir-lsp-fastreroute
From:       Gregory Mirsky <gregory.mirsky () ericsson ! com>
Date:       2013-02-27 23:40:56
Message-ID: 7347100B5761DC41A166AC17F22DF11206B373 () eusaamb103 ! ericsson ! se
[Download RAW message or body]

Dear Authors, et al.,
Please find my comments to this document below:
*       As noted in the Introduction, bi-directional co-routed LSP can be s=
ignaled in context of GMPLS model. I recall that it was agreed that all wor=
k on GMPLS constructs will be conducted within CCAMP WG.
   *    I think that scenario described in the second paragraph of the Intr=
oduction section is not correct. I believe that protection path(s) for bi-d=
irectional co-routed LSP must be bi-directional and co-routed as well. Thus=
 I don't see it possible that there will be "asymmetry of paths" after prot=
ection switchover. IMO, protection path must have the same properties as wo=
rking path, i.e. be bi-directional co-routed LSP.
   *    Asymmetry of paths may exist if working path is bi-directional asso=
ciated LSP but such construct is not in scope of this document and I believ=
e that this case fully covered by RFC 4090.
   *    Problem that you alledge in the third paragraph should not exist in=
 GMPLS with use of ASSOCIATION object (RFC 6780)
   *    I'd point that local protection with node protection for bi-directi=
onal co-routed LSP turns into a case of segment protection with OAM being r=
an between PLRs and PSC (RFC 6378) coordinating switchover by exchanging me=
ssages over protection segment.

        Regards,
                Greg

[Attachment #3 (text/html)]

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Exchange Server">

<style></style> </head>
<body>
<font face="Arial" size="2"><span style="font-size:10pt;">
<div>Dear Authors, et al.,</div>
<div>Please find my comments to this document below:</div>
<ul style="margin:0;padding-left:19pt;">
<li>As noted in the Introduction, bi-directional co-routed LSP can be signaled in \
context of GMPLS model. I recall that it was agreed that all work on GMPLS constructs \
will be conducted within CCAMP WG.</li><li>I think that scenario described in the \
second paragraph of the Introduction section is not correct. I believe that \
protection path(s) for bi-directional co-routed LSP must be bi-directional and \
co-routed as well. Thus I don't see it possible that there will be &quot;asymmetry of \
paths&quot; after protection switchover. IMO, protection path must have the same \
properties as working path, i.e. be bi-directional co-routed LSP.</li><li>Asymmetry \
of paths may exist if working path is bi-directional associated LSP but such \
construct is not in scope of this document and I believe that this case fully covered \
by RFC 4090.</li><li>Problem that you alledge in the third paragraph should not exist \
in GMPLS with use of ASSOCIATION object (RFC 6780)</li><li>I'd point that local \
protection with node protection for bi-directional co-routed LSP turns into a case of \
segment protection with OAM being ran between PLRs and PSC (RFC 6378) coordinating \
switchover by exchanging messages over protection segment.</li></ul> \
<div>&nbsp;</div> <div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Regards,</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \
Greg</div> <div>&nbsp;</div>
</span></font>
</body>
</html>

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

--===============7934660333126969051==--

[prev in list] [next in list] [prev in thread] [next in thread] 