[prev in list] [next in list] [prev in thread] [next in thread]
List: mpls
Subject: Re: [mpls] MPLS-RT review of draft-mirsky-mpls-p2mp-bfd-04
From: Greg Mirsky <gregimirsky () gmail ! com>
Date: 2018-11-19 16:42:57
Message-ID: CA+RyBmVtZ8E42DUNWm5grLc13ZddVh88=G5sE6ZbDHiN=z=ckQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Hi Andy,
thank you for your help and patience. Will do as you've suggested.
Kind regards,
Greg
On Mon, Nov 19, 2018 at 8:23 AM Andrew G. Malis <agmalis@gmail.com> wrote:
> Greg,
>
> It's looking much better, thanks.
>
> In your new text, I noticed some missing words at the end of section 3. In
> the following, I've bolded and italicized the missing words.
>
> If *the* BFD control packet *is* encapsulated in
> IP/UDP, *then* the source IP address MUST be used to demultiplex the
> received BFD control packet as described in Section 3.1. *The* non-IP
> encapsulation case *is* described in Section 3.2.
>
> Just make those changes, and then upload it for the adoption poll.
>
> Thanks again,
> Andy
>
>
>
> On Sun, Nov 18, 2018 at 5:13 PM Greg Mirsky <gregimirsky@gmail.com> wrote:
>
>> Hi Andy,
>> please find my notes and answers in-line tagged GIM2>>. All updates can
>> be reviewed in the attached diff and the working version of the draft.
>>
>> Regards,
>> Greg
>>
>> On Wed, Oct 31, 2018 at 6:41 AM Andrew G. Malis <agmalis@gmail.com>
>> wrote:
>>
>>> Greg,
>>>
>>> Thanks for checking.
>>>
>>> You didn't really address my comment: "I would have expected to see at
>>> least a reference to RFC 4687, "Operations and Management (OAM)
>>> Requirements for Point-to-Multipoint MPLS Networks", and some text on how
>>> this draft addresses the requirements in that draft.".
>>>
>> GIM>> This is not the specification for p2mp BFD. Issues of scaling and
>> performance of p2mp BFD discussed in detail in BFD for Multipoint Neworks
>> for use case of tail-only monitoring the unidirectional path, and BFD for
>> Multipoint Networks with Active Tail, for scenarios when the head uses
>> multipoint Poll sequence optionally in combination with unicasted Poll to
>> the particular tail to be aware of the state of the unidirectional path of
>> the multicast tree to tha tail. For example, the Security Considerations in
>> draft-ietf-bfd-multipoint suggest that:
>> If redundant streams are expected for a given multicast stream,
>> then the implementations should not create more MultipointTail
>> sessions than the number of streams. Additionally, when the
>> number of MultipointTail sessions exceeds the number of expected
>> streams, then the implementation should generate an alarm to users
>> to indicate the anomaly.
>>
>> The implementation should have a reasonable upper bound on the
>> number of MultipointTail sessions that can be created, with the
>> upper bound potentially being computed based on the number of
>> multicast streams that the system is expecting.
>>
>> draft-ietf-bfd-multipoint-active-tail additionally notes that:
>> implementations that create MultpointClient sessions
>> dynamically upon receipt of BFD Control packet from a tail MUST
>> implement protective measures to prevent an infinite number of
>> MultipointClient sessions being created. Below are listed some
>> points to be considered in such implementations.
>>
>> When the number of MultipointClient sessions exceeds the number of
>> expected tails, then the implementation should generate an alarm
>> to users to indicate the anomaly.
>>
>> The implementation should have a reasonable upper bound on the
>> number of MultipointClient sessions that can be created, with the
>> upper bound potentially being computed based on the number of
>> multicast streams that the system is expecting.
>>
>> In addition to these considerations listed in the base specifications for
>> p2mp BFD, I've added the following text:
>> Also, BFD for p2mp MPLS LSP MUST follow the requirements listed in
>> section 4.1 [RFC4687] to avoid congestion in the control plane or the
>> data plane caused by the rate of generating BFD control packets. An
>> operator SHOULD consider the amount of extra traffic generated by
>> p2mp BFD when selecting the interval at which the MultipointHead will
>> transmit BFD control packets. Also, the operator MAY consider the
>> size of the packet the MultipointHead transmits periodically as using
>> IP/UDP encapsulation adds up to 28 octets, which is more than 50% of
>> BFD control packet length, comparing to G-ACh encapsulation.
>>
>>
>>> You added a reference in the security section, but nothing about how
>>> your draft addresses the 4687 requirements.
>>>
>>> Also, you didn't really address my next comment: "I also expected more
>>> text on the relationship between this draft and RFC 6425, "Detecting
>>> Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping"',
>>> and more of an explanation of why the keyword MAY is used in sections 4..1
>>> and 4.2 - what are the implications of following or not following the MAY
>>> in each case?"
>>>
>>> Regarding RFC 6425, I was looking for text along the lines of why one
>>> would choose to implement this draft rather than 6425 (or both), to give
>>> product implementers and network operators guidance on whether to use 6425,
>>> this draft, or both for MPLS p2mp data plane failure detection. Otherwise,
>>> why would they bother with this draft when they already have 6425 working?
>>>
>>> Also, in sections 4.1 and 4.2, you just added another MAY to section
>>> 4.1, but again, what happens if you don't do the MAYs in both sections? Why
>>> would I want to do the MAYs? Why would I not want to? The text doesn't say.
>>>
>> GIM2>> I've expanded the text and section 4.1 of the draft now is as
>> follows:
>> LSP Ping is the part of on-demand OAM toolset to detect and localize
>> defects in the data plane, and verify the control plane against the
>> data plane by ensuring that the LSP is mapped to the same FEC, at the
>> egress, as the ingress.
>>
>> LSP Ping, as defined in [RFC6425], MAY be used to bootstrap
>> MultipointTail. If the LSP Ping used, it MUST include the Target FEC
>> TLV and the BFD Discriminator TLV defined in [RFC5884]. The Target
>> FEC TLV MUST use sub-TLVs defined in Section 3.1 [RFC6425]. It is
>> RECOMMENDED setting the value of Reply Mode field to "Do not reply"
>> [RFC8029] for the LSP Ping to bootstrap MultipointTail of the p2mp
>> BFD session. A MaultipointTail that receives the LSP Ping that
>> includes the BFD Discriminator TLV:
>>
>> o MUST validate the LSP Ping;
>>
>> o MUST associate the received BFD Discriminator value with the p2mp
>> LSP;
>>
>> o MUST create p2mp BFD session and set bfd.SessionType =
>> MultipointTail as described in [I-D.ietf-bfd-multipoint];
>>
>> o MUST use the source IP address of LSP Ping, the value of BFD
>> Discriminator from the BFD Discriminator TLV, and the identity of
>> the p2mp LSP to properly demultiplex BFD sessions.
>>
>> Besides bootstrapping a BFD session over a p2mp LSP, LSP Ping SHOULD
>> be used to verify the control plane against the data plane
>> periodically by checking that the p2mp LSP is mapped to the same FEC
>> at the MultipointHead and all active MultipointTails. The rate of
>> generation of these LSP Ping Echo request messages SHOULD be
>> significantly less than the rate of generation of the BFD Control
>> packets because LSP Ping requires more processing to validate the
>> consistency between the data plane and the control plane. An
>> implementation MAY provide configuration options to control the rate
>> of generation of the periodic LSP Ping Echo request messages.
>>
>>
>>> Finally, in section 3, the following sentence doesn't scan:
>>>
>>> The source IP
>>> address MAY be drawn from the IP header if BFD control packet
>>> transmitted by the head using IP/UDP encapsulation as described in
>>> Section 3.1.
>>>
>>> Did you mean "uses" instead of "using"?
>>>
>> GIM2>> Yes, it does need re-wording. Would this be better:
>> If BFD control packet encapsulated in
>> IP/UDP, the source IP address MUST be used to demultiplex the
>> received BFD control packet as described in Section 3.1.
>>
>>>
>>> Thanks,
>>> Andy
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Oct 30, 2018 at 11:05 AM Greg Mirsky <gregimirsky@gmail.com>
>>> wrote:
>>>
>>>> Dear Andy,
>>>> thank you for the review and the detailed suggestions. Attached please
>>>> find the updated version of the draft and the diff to highlight the
>>>> proposed changes. Please let me know if these address your comments.
>>>>
>>>> Kind regards,
>>>> Greg
>>>>
>>>> On Wed, Oct 24, 2018 at 11:11 AM Greg Mirsky <gregimirsky@gmail.com>
>>>> wrote:
>>>>
>>>>> Dear Andy,
>>>>> thank you for your thorough review and the most helpful comments. I'll
>>>>> work on the update to address them.
>>>>>
>>>>> Regards,
>>>>> Greg
>>>>>
>>>>> On Wed, Oct 24, 2018 at 9:17 AM Andrew G. Malis <agmalis@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> I've been selected as an MPLS-RT reviewer for
>>>>>> draft-mirsky-mpls-p2mp-bfd-04, which is currently a candidate for
>>>>>> MPLS WG adoption. This draft documents procedures for using BFD for
>>>>>> multipoint networks to detect data plane failures in MPLS p2mp LSPs.
>>>>>>
>>>>>> The BFD WG has been working on draft-ietf-bfd-multipoint, which
>>>>>> describes BFD procedures for multipoint and multicast networks.
>>>>>> draft-mirsky-mpls-p2mp-bfd uses that draft as a basis to detect MPLS data
>>>>>> plane failures for p2mp LSPs. This is a straightforward and useful
>>>>>> application of the BFD draft for MPLS data plane failure detection.
>>>>>>
>>>>>> However, I would have expected to see at least a reference to RFC
>>>>>> 4687, "Operations and Management (OAM) Requirements for Point-to-Multipoint
>>>>>> MPLS Networks", and some text on how this draft addresses the requirements
>>>>>> in that draft.
>>>>>>
>>>>>> I also expected more text on the relationship between this draft and
>>>>>> RFC 6425, "Detecting Data-Plane Failures in Point-to-Multipoint MPLS -
>>>>>> Extensions to LSP Ping"', and more of an explanation of why the keyword MAY
>>>>>> is used in sections 4.1 and 4.2 - what are the implications of following or
>>>>>> not following the MAY in each case?
>>>>>>
>>>>>> The draft also needs an editing pass, for example "MaultipointHead"
>>>>>> for "MultipointHead" and some incorrect English grammar in several
>>>>>> places.
>>>>>>
>>>>>> Once these items have been addressed, I think that the draft should
>>>>>> be ready for an adoption call.
>>>>>>
>>>>>> Cheers,
>>>>>> Andy
>>>>>>
>>>>>>
>>>>>>
[Attachment #5 (text/html)]
<div dir="ltr">Hi Andy,<div>thank you for your help and patience. Will do as \
you've suggested.</div><div><br></div><div>Kind \
regards,</div><div>Greg</div></div><br><div class="gmail_quote"><div dir="ltr">On \
Mon, Nov 19, 2018 at 8:23 AM Andrew G. Malis <<a \
href="mailto:agmalis@gmail.com">agmalis@gmail.com</a>> wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div dir="ltr"><div \
dir="ltr">Greg,<div><br></div><div>It's looking much better, \
thanks.</div><div><br></div><div>In your new text, I noticed some missing words at \
the end of section 3. In the following, I've bolded and italicized the missing \
words.</div><div><br></div><div><div> If <i><b>the</b></i> BFD control packet \
<i><b>is</b></i> encapsulated in</div><div> IP/UDP, <b><i>then</i></b> the source \
IP address MUST be used to demultiplex the</div><div> received BFD control packet \
as described in Section 3.1. <b><i>The</i></b> non-IP</div><div> encapsulation \
case <b><i>is</i></b> described in Section 3..2.</div></div><div><br></div><div>Just \
make those changes, and then upload it for the adoption \
poll.</div><div><br></div><div>Thanks \
again,</div><div>Andy</div><div><br></div><div><br></div></div></div><br><div \
class="gmail_quote"><div dir="ltr">On Sun, Nov 18, 2018 at 5:13 PM Greg Mirsky <<a \
href="mailto:gregimirsky@gmail.com" target="_blank">gregimirsky@gmail..com</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div \
dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi \
Andy,<div>please find my notes and answers in-line tagged GIM2>>. All updates \
can be reviewed in the attached diff and the working version of the \
draft.</div><div><br></div><div>Regards,</div><div>Greg</div><br><div \
class="gmail_quote"><div dir="ltr">On Wed, Oct 31, 2018 at 6:41 AM Andrew G. Malis \
<<a href="mailto:agmalis@gmail.com" target="_blank">agmalis@gmail.com</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div \
dir="ltr">Greg,<div><br></div><div>Thanks for checking.</div><div><br></div><div>You \
didn't really address my comment: "I would have expected to see at least a \
reference to RFC 4687, "Operations and Management (OAM) Requirements for \
Point-to-Multipoint MPLS Networks", and some text on how this draft addresses \
the requirements in that draft.". \
</div></div></div></blockquote><div>GIM>> This is not the specification for \
p2mp BFD. Issues of scaling and performance of p2mp BFD discussed in detail in BFD \
for Multipoint Neworks for use case of tail-only monitoring the unidirectional path, \
and BFD for Multipoint Networks with Active Tail, for scenarios when the head uses \
multipoint Poll sequence optionally in combination with unicasted Poll to the \
particular tail to be aware of the state of the unidirectional path of the multicast \
tree to tha tail. For example, the Security Considerations in \
draft-ietf-bfd-multipoint suggest that:</div><div><div> If redundant streams \
are expected for a given multicast stream,</div><div> then the \
implementations should not create more MultipointTail</div><div> sessions \
than the number of streams. Additionally, when the</div><div> number of \
MultipointTail sessions exceeds the number of expected</div><div> streams, \
then the implementation should generate an alarm to users</div><div> to \
indicate the anomaly.</div><div><br></div><div> The implementation should \
have a reasonable upper bound on the</div><div> number of MultipointTail \
sessions that can be created, with the</div><div> upper bound potentially \
being computed based on the number of</div><div> multicast streams that the \
system is expecting.</div><div><br></div></div><div>draft-ietf-bfd-multipoint-active-tail \
additionally notes that:<br></div><div><div>implementations that create \
MultpointClient sessions</div><div> dynamically upon receipt of BFD Control \
packet from a tail MUST</div><div> implement protective measures to prevent an \
infinite number of</div><div> MultipointClient sessions being created. Below \
are listed some</div><div> points to be considered in such \
implementations.</div><div><br></div><div> When the number of \
MultipointClient sessions exceeds the number of</div><div> expected tails, \
then the implementation should generate an alarm</div><div> to users to \
indicate the anomaly.</div><div><br></div><div> The implementation should \
have a reasonable upper bound on the</div><div> number of MultipointClient \
sessions that can be created, with the</div><div> upper bound potentially \
being computed based on the number of</div><div> multicast streams that the \
system is expecting.</div></div><div><br></div><div>In addition to these \
considerations listed in the base specifications for p2mp BFD, I've added the \
following text:</div><div> Also, BFD for p2mp MPLS LSP MUST follow the \
requirements listed in</div><div> section 4.1 [RFC4687] to avoid congestion in \
the control plane or the</div><div> data plane caused by the rate of generating \
BFD control packets. An</div><div> operator SHOULD consider the amount of extra \
traffic generated by</div><div> p2mp BFD when selecting the interval at which the \
MultipointHead will</div><div> transmit BFD control packets. Also, the operator \
MAY consider the</div><div> size of the packet the MultipointHead transmits \
periodically as using</div><div> IP/UDP encapsulation adds up to 28 octets, which \
is more than 50% of</div><div> BFD control packet length, comparing to G-ACh \
encapsulation.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px \
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div \
dir="ltr"><div dir="ltr"><div><br></div><div>You added a reference in the security \
section, but nothing about how your draft addresses the 4687 \
requirements.</div><div><br></div><div>Also, you didn't really address my next \
comment: "I also expected more text on the relationship between this draft and \
RFC 6425, "Detecting Data-Plane Failures in Point-to-Multipoint MPLS - \
Extensions to LSP Ping"', and more of an explanation of why the keyword MAY \
is used in sections 4.1 and 4.2 - what are the implications of following or not \
following the MAY in each case?"<br></div><div><br></div><div>Regarding RFC \
6425, I was looking for text along the lines of why one would choose to implement \
this draft rather than 6425 (or both), to give product implementers and network \
operators guidance on whether to use 6425, this draft, or both for MPLS p2mp data \
plane failure detection. Otherwise, why would they bother with this draft when they \
already have 6425 working?</div><div><br></div><div>Also, in sections 4.1 and 4.2, \
you just added another MAY to section 4..1, but again, what happens if you don't \
do the MAYs in both sections? Why would I want to do the MAYs? Why would I not want \
to? The text doesn't say.</div></div></div></blockquote><div>GIM2>> \
I've expanded the text and section 4.1 of the draft now is as follows:</div><div> \
LSP Ping is the part of on-demand OAM toolset to detect and localize</div><div> \
defects in the data plane, and verify the control plane against the</div><div> \
data plane by ensuring that the LSP is mapped to the same FEC, at the</div><div> \
egress, as the ingress.</div><div><br></div><div> LSP Ping, as defined in \
[RFC6425], MAY be used to bootstrap</div><div> MultipointTail. If the LSP Ping \
used, it MUST include the Target FEC</div><div> TLV and the BFD Discriminator TLV \
defined in [RFC5884]. The Target</div><div> FEC TLV MUST use sub-TLVs defined \
in Section 3.1 [RFC6425]. It is</div><div> RECOMMENDED setting the value of \
Reply Mode field to "Do not reply"</div><div> [RFC8029] for the LSP \
Ping to bootstrap MultipointTail of the p2mp</div><div> BFD session. A \
MaultipointTail that receives the LSP Ping that</div><div> includes the BFD \
Discriminator TLV:</div><div><br></div><div> o MUST validate the LSP \
Ping;</div><div><br></div><div> o MUST associate the received BFD Discriminator \
value with the p2mp</div><div> LSP;</div><div><br></div><div> o MUST \
create p2mp BFD session and set bfd.SessionType =</div><div> MultipointTail \
as described in [I-D.ietf-bfd-multipoint];</div><div><br></div><div> o MUST use \
the source IP address of LSP Ping, the value of BFD</div><div> Discriminator \
from the BFD Discriminator TLV, and the identity of</div><div> the p2mp LSP \
to properly demultiplex BFD sessions.</div><div><br></div><div> Besides \
bootstrapping a BFD session over a p2mp LSP, LSP Ping SHOULD</div><div> be used \
to verify the control plane against the data plane</div><div> periodically by \
checking that the p2mp LSP is mapped to the same FEC</div><div> at the \
MultipointHead and all active MultipointTails. The rate of</div><div> \
generation of these LSP Ping Echo request messages SHOULD be</div><div> \
significantly less than the rate of generation of the BFD Control</div><div> \
packets because LSP Ping requires more processing to validate the</div><div> \
consistency between the data plane and the control plane. An</div><div> \
implementation MAY provide configuration options to control the rate</div><div> \
of generation of the periodic LSP Ping Echo request \
messages.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px \
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div \
dir="ltr"><div dir="ltr"><div><br></div><div>Finally, in section 3, the following \
sentence doesn't scan:</div><div><br></div><div><div> The source \
IP</div><div> address MAY be drawn from the IP header if BFD control \
packet</div><div> transmitted by the head using IP/UDP encapsulation as described \
in</div><div> Section 3.1.</div></div><div><br></div><div>Did you mean \
"uses" instead of \
"using"?</div></div></div></blockquote><div>GIM2>> Yes, it does need \
re-wording. Would this be better:</div><div> If BFD control packet encapsulated \
in</div><div> IP/UDP, the source IP address MUST be used to demultiplex \
the</div><div> received BFD control packet as described in Section \
3.1.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div \
dir="ltr"><div><br></div><div>Thanks,</div><div>Andy</div><div><br></div><div><br></div><div><br></div><div><br></div></div></div><br><div \
class="gmail_quote"><div dir="ltr">On Tue, Oct 30, 2018 at 11:05 AM Greg Mirsky \
<<a href="mailto:gregimirsky@gmail.com" \
target="_blank">gregimirsky@gmail.com</a>> wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div dir="ltr">Dear Andy,<div>thank you for the \
review and the detailed suggestions. Attached please find the updated version of the \
draft and the diff to highlight the proposed changes. Please let me know if these \
address your comments.</div><div><br></div><div>Kind \
regards,</div><div>Greg</div></div><br><div class="gmail_quote"><div dir="ltr">On \
Wed, Oct 24, 2018 at 11:11 AM Greg Mirsky <<a href="mailto:gregimirsky@gmail.com" \
target="_blank">gregimirsky@gmail.com</a>> wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div dir="ltr">Dear Andy,<div>thank you for your \
thorough review and the most helpful comments. I'll work on the update to address \
them.</div><div><br></div><div>Regards,</div><div>Greg</div></div><br><div \
class="gmail_quote"><div dir="ltr">On Wed, Oct 24, 2018 at 9:17 AM Andrew G. Malis \
<<a href="mailto:agmalis@gmail.com" target="_blank">agmalis@gmail.com</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div \
dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">I've been \
selected as an <span \
class="m_2483977285687700436m_-5826172632188621694gmail-m_5452134630101505754gmail-m_8 \
009674773234651919m_-7976541164438037522m_4836479175083463128m_7206569783012449796m_-1369470530874045245gmail-il">MPLS</span>-<span \
class="m_2483977285687700436m_-5826172632188621694gmail-m_5452134630101505754gmail-m_8 \
009674773234651919m_-7976541164438037522m_4836479175083463128m_7206569783012449796m_-1369470530874045245gmail-il">RT</span> \
reviewer for draft-mirsky-mpls-p2mp-bfd-04, which is currently a candidate for <span \
class="m_2483977285687700436m_-5826172632188621694gmail-m_5452134630101505754gmail-m_8 \
009674773234651919m_-7976541164438037522m_4836479175083463128m_7206569783012449796m_-1369470530874045245gmail-il">MPLS</span> \
WG adoption. This draft documents procedures for using BFD for multipoint networks to \
detect data plane failures in MPLS p2mp LSPs.<div><br></div><div>The BFD WG has been \
working on draft-ietf-bfd-multipoint, which describes BFD procedures for multipoint \
and multicast networks. draft-mirsky-mpls-p2mp-bfd uses that draft as a basis to \
detect MPLS data plane failures for p2mp LSPs. This is a straightforward and useful \
application of the BFD draft for MPLS data plane failure \
detection.</div><div><br></div><div>However, I would have expected to see at least a \
reference to RFC 4687, "Operations and Management (OAM) Requirements for \
Point-to-Multipoint MPLS Networks", and some text on how this draft addresses \
the requirements in that draft.</div><div><br></div><div>I also expected more text on \
the relationship between this draft and RFC 6425, "Detecting Data-Plane Failures \
in Point-to-Multipoint MPLS - Extensions to LSP Ping"', and more of an \
explanation of why the keyword MAY is used in sections 4.1 and 4.2 - what are the \
implications of following or not following the MAY in each \
case?</div><div><br></div><div>The draft also needs an editing pass, for example \
"<span style="color:rgb(0,0,0);font-size:13.3333px">MaultipointHead" for \
"</span><span style="color:rgb(0,0,0);font-size:13.3333px">MultipointHead" \
and some incorrect English grammar in several \
places.</span></div><div><br></div><div>Once these items have been addressed, I think \
that the draft should be ready for an adoption \
call.</div><div><br></div><div>Cheers,</div><div>Andy</div><div><br></div><div><span \
style="color:rgb(0,0,0);font-size:13.3333px"><br></span></div></div></div></div></div></div></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div></div></div></div></div></div></div></div>
</blockquote></div>
</blockquote></div>
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic