Re: [Pals] IPR poll for draft-jain-pals-p2mp-pw-lsp-ping

["Parag Jain (paragj)" <[e-mail]>]

Hi Greg

Thanks for your comments. Please see inline.


From: Gregory Mirsky <[e-mail]<mailto:[e-mail]>>
Date: Monday, May 9, 2016 at 1:55 PM
To: "Andrew G. Malis" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: [Pals] IPR poll for draft-jain-pals-p2mp-pw-lsp-ping
Resent-From: <[e-mail]<mailto:[e-mail]>>
Resent-To: Parag Jain <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>
Resent-Date: Monday, May 9, 2016 at 1:55 PM

Dear Authors, et. al,
though the adoption call had not yet started, please consider my notes in the that context.
I've read the draft and support its adoption.
Now to comments:

·         Introduction states "P2MP PWs are carried over P2MP MPLS LSP". But RFC 7338 states that p2mp PW MAY support return path which makes it bi-directional or E-Tree-like. Then p2mp LSP cannot serve as transport since  MPLS LSPs, in general, are unidirectional objects. Even in MPLS-TP p2mp LSP is unidirectional and only p2p LSP may be bidirectional. Should it be a tunnel, rather than MPLS LSP?

The available solutions for p2mp PW ride on p2mp MPLS LSPs today, as per solution draft/rfc in pals and bess, we are providing OAM service for those solutions.


·         I think that it would be beneficial to discuss and demonstrate why FEC 129 PW cannot be used, re-used for p2mp PW.

·         could appropriate p2p LSP FEC and p2mp pw FEC be combined?

The current solution draft in pals uses FEC130, we simply providing LSP Ping support for the new FEC as per the solution draft.


·         Section 5:

o   Is IPv4 the only address family to be supported? AFAIK, IPv6 address family may be used as well and thus ACH 0x0057 used

that's right. If the ping is using ipv6 dresses, will use ACH 0x0057. Will update the draft.


o   There's no need to use GAL when sending OAM packets over PW VCCV as PW ACH identifies the PW VCCV

GAL is as well one of the mechanisms that can be used with OAM packets.


·         Which return paths can be used for Echo Reply? I believe that because RFC 7338 states that p2mp PW may be bi-directional, there may be alternative to Reply Mode value 2, i.e. out-band reply over IPv4/IPv6 network.

The reply can be out  of band using ipv4/ipv6 or p2p pw from leaf to root node if root node signalled optional p2p pw. Will update the draft.

Thanks
Parag


Regards,
                        Greg

From: Pals [mailto:[e-mail]] On Behalf Of Andrew G. Malis
Sent: Monday, May 09, 2016 7:47 AM
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: [Pals] IPR poll for draft-jain-pals-p2mp-pw-lsp-ping

Working Group,

https://tools.ietf.org/html/draft-jain-pals-p2mp-pw-lsp-ping-01 has been
requested for PALS working group adoption.

We will conduct an IPR poll before the adoption poll is started.

Are you aware of any IPR that applies to draft-jain-pals-p2mp-pw-lsp-ping?

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details)?

There are no IPR disclosures currently filed against this document.

If you are listed as a document author or contributor please respond to
this email regardless of whether or not you are aware of any relevant
IPR. *The response needs to be sent to the PALS WG email list.* The
document will not advance to the next stage until a response has been
received from each author and contributor.

If you are on the PALS WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of any
IPR that has not yet been disclosed in conformance with IETF rules.

This call will remain open until we've heard back from all of the authors and contributors.

Thanks,
Andy