[prev in list] [next in list] [prev in thread] [next in thread]
List: mpls
Subject: Re: [mpls] MPLS WG adoption call for draft-mirsky-mpls-p2mp-bfd
From: "Carlos Pignataro (cpignata)" <cpignata () cisco ! com>
Date: 2018-11-24 18:52:06
Message-ID: 88AC4C8C-C945-4B46-BA8D-42EDAA2EBEC8 () cisco ! com
[Download RAW message or body]
[Attachment #2 (text/plain)]
Hi Greg,
On Nov 21, 2018, at 7:00 AM, Greg Mirsky \
<gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>> wrote:
Hi Carlos,
apologies for the prolonged silence. Thank you for your consideration of the proposed \
new text and the acknowledgment that we're converging.
I do not recall (nor can I find below) any text from me with any acknowledgement of \
convergence. That is a misrepresentation.
I do see you (not I) wrote below again ("Glad that we're converging.") I do not see \
the basis for that.
I did tell Loa I saw progress (not convergence) but also that my main question \
remained, in my humble opinion, unsatisfactorily answered.
Please find the new comments in-line tagged GIM3>>.
Regards,
Greg
On Wed, Nov 7, 2018 at 8:52 PM Carlos Pignataro (cpignata) \
<cpignata@cisco.com<mailto:cpignata@cisco.com>> wrote: [Greg, Loa, responding to both \
on this single email reply]
Hi, Loa,
On Nov 6, 2018, at 1:49 PM, Loa Andersson <loa@pi.nu<mailto:loa@pi.nu>> wrote:
Carlos,
Since the a wg adoption poll I read your comments as that we are doing
progress, and that we can address the rest during the wg process,
correct?
I agree we are making progress, thank you. Most questions can be addressed later, but \
only the very first question goes to the heart of an adoption poll. If we can close \
on that, the rest can be addressed later (note the same question is related also to \
the last question.)
/Loa
Hi, Greg,
Thank you very much for your responses — please see inline.
On Nov 6, 2018, at 7:18 PM, Greg Mirsky \
<gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>> wrote:
Hi Carlos,
thank you for your consideration of my responses. Glad that we're converging. Please \
find additional notes in-line tagged GIM2>>.
Regards,
Greg
On Tue, Nov 6, 2018 at 12:11 AM Carlos Pignataro (cpignata) \
<cpignata@cisco.com<mailto:cpignata@cisco.com>> wrote: Hi Greg,
Many thanks for your response and suggestions! Please see inline.
On Nov 2, 2018, at 6:13 AM, Greg Mirsky \
<gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>> wrote:
Hi Carlos,
thank you for your comments. Please find my notes, answers in-line tagged GIM>>.
Regards,
Greg
On Thu, Oct 25, 2018 at 8:47 PM Carlos Pignataro (cpignata) \
<cpignata@cisco.com<mailto:cpignata@cisco.com>> wrote: Hi,
Cc BFD WG
It would be useful to understand the use case motivation or applicability of this \
draft, other than it can be done. GIM>> The motivation can be seen in the following \
(from another draft that discusses OAM over G-ACh: In some
environments, the overhead of extra IP/UDP encapsulations may be
considered as overburden and make using more compact G-ACh
encapsulation attractive.
Will add text in the draft.
CMP: Thank you very much. This is a good start, although it would be useful to add \
precision into which environments specifically, and the burden comparison between \
IP/UDP and G-ACh. GIM2>> Thank you for agreeing to this, and I've added the text in \
the working verion. Will work on improving the text in the meantime.
CMP: Sorry if I was not clear. Like I said, this is a good start and probably \
necessary (but not sufficient) text.
CMP: Which environments specifically? At this point, the scope and target of the work \
is not clear to me. That was my question. Is this for MPLS-TP P2MP? If so, the \
underlying seems to have stalled: \
https://datatracker.ietf.org/doc/rfc7167/referencedby/
CMP: I think these two questions should be answered: 1. What specific environments? \
2. How current solutions do not solve it (i.e., what is and can we quantify the \
overburden)? GIM3>> Andy Malis has pointed to the requirements for proactive OAM, \
particularly monitoring path continuity, listed in Section 4.1 RFC 4687.
Just to understand — the basis of this work is Requirements from RFC 4687 from the \
year 2006?
These are not specific to MPLS-TP but to OAM over p2mp MPLS LSP. The following text \
has been added to the Security Considerations section in the recenly uploaded -04 \
version of the draft:
Adding scope and rationale for some work in the Security Considerations does not seem \
like the right sequentiality to set the stage.
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.
I'm also increasingly concerned by confusing scope and definition of specifications.
For example:
https://tools.ietf.org/html/draft-mirsky-mpls-p2mp-bfd-04#section-3.2
3.2. Non-IP Encapsulation of Multipoint BFD
Non-IP encapsulation for multipoint BFD over p2mp MPLS LSP MUST use
Generic Associated Channel (G-ACh) Label (GAL) [RFC5586] at the
bottom of the label stack followed by Associated Channel Header
(ACH). Channel Type field in ACH MUST be set to BFD CV [RFC6428].
First, there's no definition for non-IP BFD in RFC 5586 — only in RFC 5885.
GIM>> RFC 5586 defined the use of GAL. I think that this reference is appropriate. I \
agree that the second reference should be to RFC 5885, not RFC 6428. Will make the \
change.
CMP: Thank you. However, RFC 5885 is in the context of PW VCCV — is there a missing \
definition in the specs for BFD over G-ACh generically? GIM2>> I think that the \
following quote from RFC 5586 set the relationship between Channel Type field in PW \
ACH and G-ACh: Channel Types for the Associated Channel Header are allocated from
the IANA "PW Associated Channel Type" registry [RFC4446].
I understand that that there's one and only one registry and channel values are \
equally applicable to PW ACH and G-ACh. And full name of the registry now is MPLS \
Generalized Associated Channel (G-ACh) Types (including Pseudowire Associated Channel \
Types).
CMP: That is correct. I was curious as to whether additional control plane is needed \
for this support.
Second, the specification in RFC 6428 applies to MPLS Transport Profile only. NOT for \
MPLS, and explicitly NOT for P2MP!
https://tools.ietf.org/html/rfc6428#section-1
This document specifies the BFD extension and behavior to satisfy the
CC, proactive CV monitoring, and the RDI functional requirements for
both co-routed and associated bidirectional LSPs. Supported
encapsulations include Generic Associated Channel Label (GAL) /
Generic Associated Channel (G-ACh), Virtual Circuit Connectivity
Verification (VCCV), and UDP/IP. Procedures for unidirectional
point-to-point (P2P) and point-to-multipoint (P2MP) LSPs are for
further study.
So, no, this does not work.
RFC 6428 does not have scope for P2MP.
And RFC 5586 does not specify anything for BFD. Instead, what needs to be cited \
(appropriately and expanded) is RFC 5885 GIM>> RFC 5586 specifies the use of GAL and \
G-ACh and the reference is used in this context.
CMP: This is the same comment as above.
https://tools.ietf.org/html/rfc6428#section-4
RFC 5884 - BFD CC in UDP/IP/LSP
RFC 5885 - BFD CC in G-ACh
GIM>> I'd point that it is for p2p BFD CC, and p2mp BFD uses different from p2p BFD \
method to demultiplex BFD control packets.
CMP: Apologies I did not understand this response.
GIM2>> Apologies for sending partial explanation. P2MP BFD cannot use Your \
Discriminator field to demultiplex the recieved BFD control packet. BFD for \
Multipoint Networks defines the special procedure that requires the use of Source ID. \
When the encapsulation of BFD control packet does not include IP/UDP header, the \
Source ID can be provided as Source MEP-ID TLV in MPLS-TP BFD CV. This draft proposes \
the new IP Address TLV for that. Thus I have to correct myself and re-state the \
earlier text in the draft that the value in the Channel Type filed of G-ACh must be \
MPLS-TP CV (0x0023).
CMP: I understood you said above that the reference to RFC6428 was incorrect.
CMP: Now, just to understand the approach:
CMP: Are you suggesting that the IP header is not used with BFD and instead a new TLV \
(of which information structure?) carries the IP address that you removed before? \
Seems like a musical-chairs arrangement of the data. I may very likely be missing \
something. Apologies in advance if that is the case.
CMP: Also, is the applicability MPLS-TP? What is the normative reference for MPLS-TP \
P2MP? GIM3>> I should have explained why I think that MPLS-TP CV message (0x0023) \
type is more suitable than BFD Control, PW-ACH encapsulation (without IP/UDP Headers) \
(0x0007). The latter includes only the BFD control packet while the format of the \
former includes Source MEP-ID TLV that immediately follows the BFD control packet. \
And with the new proposed IP Address TLV the 0x0023 G-ACh channel works better for \
p2mp BFD over p2mp MPLS LSP. Alternative, of course, would be to define the new G-ACh \
type for p2mp BFD over p2mp MPLS LSP.
Thanks — I appreciate that a lot of packet formats could be drawn. My question is \
really regarding motivation for the work (the vague " In some environments")
Thanks,
— Carlos.
Thanks,
Carlos.
CMP: Thanks again for considering the comment to improve the document.
Thanks,
Carlos.
RFC 5085 - UDP/IP in G-ACh
MPLS-TP - CC/CV in GAL/G-ACh or G-ACh
Thanks,
— Carlos Pignataro
On Oct 13, 2018, at 4:24 PM, Greg Mirsky \
<gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>> wrote:
Dear WG Chairs, et al.,
as the author of the BFD for Multipoint Networks over Point-to-Multi-Point MPLS LSP \
(draft-mirsky-mpls-p2mp-bfd) I would like to ask you to consider WG adoption call of \
the draft. The document addresses non-IP encapsulation of p2mp BFD over MPLS LSP that \
may be useful if the overhead of IP, particularly IPv6, encapsulation is the concern. \
The base specification of BFD for Multipoint Networks is at this time in IESG LC.
Regards,
Greg
_______________________________________________
mpls mailing list
mpls@ietf.org<mailto:mpls@ietf.org>
https://www.ietf.org/mailman/listinfo/mpls
[Attachment #3 (text/html)]
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: \
after-white-space;" class=""> Hi Greg,
<div class="">
<div class=""><br class="">
</div>
<div>
<blockquote type="cite" class="">
<div class="">On Nov 21, 2018, at 7:00 AM, Greg Mirsky <<a \
href="mailto:gregimirsky@gmail.com" class="">gregimirsky@gmail.com</a>> \
wrote:</div> <br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">
<div dir="ltr" class="">
<div dir="ltr" class="">
<div dir="ltr" class="">
<div dir="ltr" class="">Hi Carlos,
<div class="">apologies for the prolonged silence. Thank you for your consideration \
of the proposed new text and the acknowledgment that we're converging.</div> </div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>I do not recall (nor can I find below) any text from me with any acknowledgement \
of convergence. That is a misrepresentation.</div> <div><br class="">
</div>
<div>I do see you (not I) wrote below again ("Glad that we're converging.") I do not \
see the basis for that.</div> <div><br class="">
</div>
<div>I did tell Loa I saw progress (not convergence) but also that my main question \
remained, in my humble opinion, unsatisfactorily answered.</div> <div><br class="">
</div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">
<div dir="ltr" class="">
<div dir="ltr" class="">
<div dir="ltr" class="">
<div dir="ltr" class="">
<div class="">Please find the new comments in-line tagged GIM3>>.</div>
<div class=""><br class="">
</div>
<div class="">Regards,</div>
<div class="">Greg</div>
<br class="">
<div class="gmail_quote">
<div dir="ltr" class="">On Wed, Nov 7, 2018 at 8:52 PM Carlos Pignataro (cpignata) \
<<a href="mailto:cpignata@cisco.com" class="">cpignata@cisco.com</a>> wrote:<br \
class=""> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"> <div style="overflow-wrap: break-word;" \
class="">[Greg, Loa, responding to both on this single email reply] <div class=""><br \
class=""> </div>
<div class="">Hi, Loa,</div>
<div class=""><br class="">
</div>
<div class="">
<div class="">
<blockquote type="cite" class="">
<div class="">On Nov 6, 2018, at 1:49 PM, Loa Andersson <<a \
href="mailto:loa@pi.nu" target="_blank" class="">loa@pi.nu</a>> wrote:</div> <br \
class="gmail-m_-8048155264872142171Apple-interchange-newline"> <div \
class="">Carlos,<br class=""> <br class="">
Since the a wg adoption poll I read your comments as that we are doing<br class="">
progress, and that we can address the rest during the wg process,<br class="">
correct?<br class="">
<br class="">
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">I agree we are making progress, thank you. Most questions can be \
addressed later, but only the very first question goes to the heart of an adoption \
poll. If we can close on that, the rest can be addressed later (note the same \
question is related also to the last question.)</div>
<br class="">
<blockquote type="cite" class="">
<div class="">/Loa<br class="">
</div>
</blockquote>
</div>
<div class=""><br class="">
</div>
<div class="">Hi, Greg,</div>
<div class=""><br class="">
</div>
<div class="">Thank you very much for your responses — please see inline.</div>
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">On Nov 6, 2018, at 7:18 PM, Greg Mirsky <<a \
href="mailto:gregimirsky@gmail.com" target="_blank" \
class="">gregimirsky@gmail.com</a>> wrote:</div> <br \
class="gmail-m_-8048155264872142171Apple-interchange-newline"> <div class="">
<div dir="ltr" class="">
<div dir="ltr" class="">
<div dir="ltr" class="">Hi Carlos,
<div class="">thank you for your consideration of my responses. Glad that we're \
converging. Please find additional notes in-line tagged GIM2>>.</div> <div \
class=""><br class=""> </div>
<div class="">Regards,</div>
<div class="">Greg</div>
<br class="">
<div class="gmail_quote">
<div dir="ltr" class="">On Tue, Nov 6, 2018 at 12:11 AM Carlos Pignataro (cpignata) \
<<a href="mailto:cpignata@cisco.com" target="_blank" \
class="">cpignata@cisco.com</a>> wrote:<br class=""> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"> <div class="">Hi Greg,
<div class=""><br class="">
</div>
<div class="">Many thanks for your response and suggestions! Please see inline.</div>
<div class=""><br class="">
<div class="">
<blockquote type="cite" class="">
<div class="">On Nov 2, 2018, at 6:13 AM, Greg Mirsky <<a \
href="mailto:gregimirsky@gmail.com" target="_blank" \
class="">gregimirsky@gmail.com</a>> wrote:</div> <br \
class="gmail-m_-8048155264872142171gmail-m_2939641602688262668Apple-interchange-newline">
<div class="">
<div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-vari \
ant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent: \
0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none" \
class=""> <div dir="ltr" class="">Hi Carlos,
<div class="">thank you for your comments. Please find my notes, answers in-line \
tagged GIM>>.</div> <div class=""><br class="">
</div>
<div class="">Regards,</div>
<div class="">Greg<br class="">
<br class="">
<div class="gmail_quote">
<div dir="ltr" class="">On Thu, Oct 25, 2018 at 8:47 PM Carlos Pignataro (cpignata) \
<<a href="mailto:cpignata@cisco.com" target="_blank" \
class="">cpignata@cisco.com</a>> wrote:<br class=""> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"> <div class="">Hi,
<div class=""><br class="">
</div>
<div class="">Cc BFD WG</div>
<div class=""><br class="">
</div>
<div class="">It would be useful to understand the use case motivation or \
applicability of this draft, other than it can be done.</div> </div>
</blockquote>
<div class="">GIM>> The motivation can be seen in the following (from \
another draft that discusses OAM over G-ACh:</div> <div class="">
<div class=""> In some</div>
<div class=""> environments, the overhead of extra IP/UDP encapsulations \
may be</div> <div class=""> considered as overburden and make using more \
compact G-ACh</div> <div class=""> encapsulation attractive.</div>
</div>
<div class="">Will add text in the draft.</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">CMP: Thank you very much. This is a good start, although it would be \
useful to add precision into which environments specifically, and the burden \
comparison between IP/UDP and G-ACh.</div> </div>
</div>
</div>
</blockquote>
<div class="">GIM2>> Thank you for agreeing to this, and I've added the text in \
the working verion. Will work on improving the text in the meantime.</div> </div>
</div>
</div>
</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">CMP: Sorry if I was not clear. Like I said, this is a good start and \
probably necessary (but not sufficient) text.</div> <div class=""><br class="">
</div>
<div class="">CMP: Which environments specifically? At this point, the scope and \
target of the work is not clear to me. That was my question. Is this for MPLS-TP \
P2MP? If so, the underlying seems to have stalled: </div> <div class=""><a \
href="https://datatracker.ietf.org/doc/rfc7167/referencedby/" target="_blank" \
class="">https://datatracker.ietf.org/doc/rfc7167/referencedby/</a></div> <div \
class="">CMP: I think these two questions should be answered: 1. What specific \
environments? 2. How current solutions do not solve it (i.e., what is and can we \
quantify the overburden)?</div> </div>
</div>
</div>
</blockquote>
<div class="">GIM3>> Andy Malis has pointed to the requirements for proactive \
OAM, particularly monitoring path continuity, listed in Section 4.1 RFC 4687. </div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>Just to understand — the basis of this work is Requirements from RFC 4687 from \
the year 2006?</div> <div><br class="">
</div>
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">
<div dir="ltr" class="">
<div dir="ltr" class="">
<div dir="ltr" class="">
<div dir="ltr" class="">
<div class="gmail_quote">
<div class="">These are not specific to MPLS-TP but to OAM over p2mp MPLS LSP. The \
following text has been added to the Security Considerations section in the recenly \
uploaded -04 version of the draft:</div> </div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>Adding scope and rationale for some work in the Security Considerations does not \
seem like the right sequentiality to set the stage.</div> <br class="">
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">
<div dir="ltr" class="">
<div dir="ltr" class="">
<div dir="ltr" class="">
<div dir="ltr" class="">
<div class="gmail_quote">
<div class="">
<div class=""> Also, BFD for p2mp MPLS LSP MUST follow the requirements \
listed in</div> <div class=""> section 4.1 [RFC4687] to avoid congestion \
in the control plane or the</div> <div class=""> data plane caused by the \
rate of generating BFD control packets. An</div> <div class=""> \
operator SHOULD consider the amount of extra traffic generated by</div> <div \
class=""> p2mp BFD when selecting the interval at which the \
MultipointHead will</div> <div class=""> transmit BFD control \
packets. Also, the operator MAY consider the</div> <div class=""> \
size of the packet the MultipointHead transmits periodically as using</div> \
<div class=""> IP/UDP encapsulation adds up to 28 octets, which is more \
than 50% of</div> <div class=""> BFD control packet length, comparing to \
G-ACh encapsulation.</div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"> <div style="overflow-wrap: break-word;" class="">
<div class="">
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">
<div dir="ltr" class="">
<div dir="ltr" class="">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"> <div class="">
<div class="">
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-vari \
ant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent: \
0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none" \
class=""> <div dir="ltr" class="">
<div class="">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"> <div class="">
<div class=""><br class="">
</div>
<div class="">I'm also increasingly concerned by confusing scope and definition of \
specifications.</div> <div class=""><br class="">
</div>
<div class="">For example:</div>
<div class=""><br class="">
</div>
<div class=""><a href="https://tools.ietf.org/html/draft-mirsky-mpls-p2mp-bfd-04#section-3.2" \
target="_blank" class="">https://tools.ietf.org/html/draft-mirsky-mpls-p2mp-bfd-04#section-3.2</a></div>
<div class=""><br class="">
</div>
<div class="">3.2. Non-IP Encapsulation of Multipoint BFD
<div class=""><br class="">
</div>
<div class=""> Non-IP encapsulation for multipoint BFD over p2mp MPLS LSP \
MUST use</div> <div class=""> Generic Associated Channel (G-ACh) Label \
(GAL) [RFC5586] at the</div> <div class=""> bottom of the label stack \
followed by Associated Channel Header</div> <div class=""> (ACH). \
Channel Type field in ACH MUST be set to BFD CV [RFC6428].</div> <br \
class="gmail-m_-8048155264872142171gmail-m_2939641602688262668gmail-m_-5992720512572016398Apple-interchange-newline">
<br class="">
</div>
<div class="">First, there's no definition for non-IP BFD in RFC 5586 — only in RFC \
5885.</div> </div>
</blockquote>
<div class="">GIM>> RFC 5586 defined the use of GAL. I think that this \
reference is appropriate. I agree that the second reference should be to RFC 5885, \
not RFC 6428. Will make the change.</div> </div>
</div>
</div>
</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">CMP: Thank you. However, RFC 5885 is in the context of PW VCCV — is \
there a missing definition in the specs for BFD over G-ACh generically?</div> </div>
</div>
</div>
</blockquote>
<div class="">GIM2>> I think that the following quote from RFC 5586 set the \
relationship between Channel Type field in PW ACH and G-ACh:</div> <div \
class=""> Channel Types for the Associated Channel Header are allocated \
from</div> <div class=""> the IANA "PW Associated Channel \
Type" registry [RFC4446]. </div> <div class="">I understand that that \
there's one and only one registry and channel values are equally applicable to PW ACH \
and G-ACh. And full name of the registry now is MPLS Generalized Associated \
Channel (G-ACh) Types (including Pseudowire Associated Channel Types).</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">CMP: That is correct. I was curious as to whether additional control \
plane is needed for this support.</div> <br class="">
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">
<div dir="ltr" class="">
<div dir="ltr" class="">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"> <div class="">
<div class="">
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-vari \
ant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent: \
0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none" \
class=""> <div dir="ltr" class="">
<div class="">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"> <div class="">
<div class="">Second, the specification in RFC 6428 applies to MPLS Transport \
Profile only. NOT for MPLS, and explicitly NOT for P2MP!</div> <div class=""><br \
class=""> </div>
<div class=""><a href="https://tools.ietf.org/html/rfc6428#section-1" target="_blank" \
class="">https://tools.ietf.org/html/rfc6428#section-1</a></div> <div class=""><br \
class=""> </div>
<div class="">
<div class=""> This document specifies the BFD extension and behavior to \
satisfy the</div> <div class=""> CC, proactive CV monitoring, and the RDI \
functional requirements for</div> <div class=""> both co-routed and \
associated bidirectional LSPs. Supported</div> <div class=""> \
encapsulations include Generic Associated Channel Label (GAL) /</div> <div \
class=""> Generic Associated Channel (G-ACh), Virtual Circuit \
Connectivity</div> <div class=""> Verification (VCCV), and UDP/IP. \
Procedures for unidirectional</div> <div class=""> point-to-point (P2P) \
and point-to-multipoint (P2MP) LSPs are for</div> <div class=""> further \
study.</div> <br class="gmail-m_-8048155264872142171gmail-m_2939641602688262668gmail-m_-5992720512572016398Apple-interchange-newline">
<br class="">
</div>
<div class="">So, no, this does not work.</div>
<div class=""><br class="">
</div>
<div class="">RFC 6428 does not have scope for P2MP.</div>
<div class="">And RFC 5586 does not specify anything for BFD. Instead, what needs to \
be cited (appropriately and expanded) is RFC 5885</div> </div>
</blockquote>
<div class="">GIM>> RFC 5586 specifies the use of GAL and G-ACh and the \
reference is used in this context.</div> </div>
</div>
</div>
</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">CMP: This is the same comment as above.</div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-vari \
ant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent: \
0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none" \
class=""> <div dir="ltr" class="">
<div class="">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"> <div class="">
<div class=""><br class="">
</div>
<div class=""><a href="https://tools.ietf.org/html/rfc6428#section-4" target="_blank" \
class="">https://tools.ietf.org/html/rfc6428#section-4</a></div> <div class=""> \
RFC 5884 - BFD CC in UDP/IP/LSP <div class=""> \
RFC 5885 - BFD CC in G-ACh </div> </div>
</div>
</blockquote>
<div class="">GIM>> I'd point that it is for p2p BFD CC, and p2mp BFD uses \
different from p2p BFD method to demultiplex BFD control packets. </div> </div>
</div>
</div>
</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
CMP: Apologies I did not understand this response.</div>
</div>
</div>
</blockquote>
<div class="">GIM2>> Apologies for sending partial explanation. P2MP BFD cannot \
use Your Discriminator field to demultiplex the recieved BFD control packet. BFD for \
Multipoint Networks defines the special procedure that requires the use of Source ID. \
When the encapsulation of BFD control packet does not include IP/UDP header, the \
Source ID can be provided as Source MEP-ID TLV in MPLS-TP BFD CV. This draft proposes \
the new IP Address TLV for that. Thus I have to correct myself and re-state the \
earlier text in the draft that the value in the Channel Type filed of G-ACh must be \
MPLS-TP CV (0x0023).</div> </div>
</div>
</div>
</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">CMP: I understood you said above that the reference to RFC6428 was \
incorrect. </div> <div class=""><br class="">
</div>
<div class="">CMP: Now, just to understand the approach: </div>
<div class=""><br class="">
</div>
<div class="">CMP: Are you suggesting that the IP header is not used with BFD and \
instead a new TLV (of which information structure?) carries the IP address that you \
removed before? Seems like a musical-chairs arrangement of the data. I may very \
likely be missing something. Apologies in advance if that is the case.</div>
<div class=""><br class="">
</div>
<div class="">CMP: Also, is the applicability MPLS-TP? What is the normative \
reference for MPLS-TP P2MP?</div> </div>
</div>
</div>
</blockquote>
<div class="">GIM3>> I should have explained why I think that MPLS-TP CV \
message (0x0023) type is more suitable than BFD Control, PW-ACH encapsulation \
(without IP/UDP Headers) (0x0007). The latter includes only the BFD control packet \
while the format of the former includes Source MEP-ID TLV that immediately follows \
the BFD control packet. And with the new proposed IP Address TLV the 0x0023 G-ACh \
channel works better for p2mp BFD over p2mp MPLS LSP. Alternative, of course, would \
be to define the new G-ACh type for p2mp BFD over p2mp MPLS LSP.</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"> <div style="overflow-wrap: break-word;" class="">
<div class="">
<div class="">
<div class=""><br class="">
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>Thanks — I appreciate that a lot of packet formats could be drawn. My question \
is really regarding motivation for the work (the vague " In some environments")</div> \
<div><br class=""> </div>
<div>Thanks,</div>
<div><br class="">
</div>
<div>— Carlos.</div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">
<div dir="ltr" class="">
<div dir="ltr" class="">
<div dir="ltr" class="">
<div dir="ltr" class="">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"> <div style="overflow-wrap: break-word;" class="">
<div class="">
<div class="">
<div class=""></div>
<div class="">Thanks,</div>
<div class=""><br class="">
</div>
<div class="">Carlos.</div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">
<div dir="ltr" class="">
<div dir="ltr" class="">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"> <div class="">
<div class="">
<div class=""><br class="">
</div>
<div class="">CMP: Thanks again for considering the comment to improve the \
document.</div> <div class=""><br class="">
</div>
<div class="">Thanks,</div>
<div class=""><br class="">
</div>
<div class="">Carlos.</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-vari \
ant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent: \
0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none" \
class=""> <div dir="ltr" class="">
<div class="">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"> <div class="">
<div class="">
<div class=""> RFC 5085 - UDP/IP in G-ACh</div>
<div class=""> MPLS-TP - CC/CV in GAL/G-ACh or G-ACh</div>
<br class="gmail-m_-8048155264872142171gmail-m_2939641602688262668gmail-m_-5992720512572016398Apple-interchange-newline">
<br class="">
</div>
<div class=""><br class="">
<div class="">
<div dir="auto" class="">
<div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:n \
ormal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none" \
class=""> Thanks,</div>
<div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:n \
ormal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none" \
class=""> <br class="">
</div>
<div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:n \
ormal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none" \
class=""> — Carlos Pignataro</div>
</div>
</div>
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">On Oct 13, 2018, at 4:24 PM, Greg Mirsky <<a \
href="mailto:gregimirsky@gmail.com" target="_blank" \
class="">gregimirsky@gmail.com</a>> wrote:</div> <br \
class="gmail-m_-8048155264872142171gmail-m_2939641602688262668gmail-m_-5992720512572016398Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">Dear WG Chairs, et al.,
<div class="">as the author of the BFD for Multipoint Networks over \
Point-to-Multi-Point MPLS LSP (draft-mirsky-mpls-p2mp-bfd) I would like to ask you to \
consider WG adoption call of the draft. The document addresses non-IP encapsulation \
of p2mp BFD over MPLS LSP that may be useful if the overhead of IP, particularly \
IPv6, encapsulation is the concern. The base specification of BFD for Multipoint \
Networks is at this time in IESG LC.</div> <div class=""><br class="">
</div>
<div class="">Regards,</div>
<div class="">Greg</div>
</div>
_______________________________________________<br class="">
mpls mailing list<br class="">
<a href="mailto:mpls@ietf.org" target="_blank" class="">mpls@ietf.org</a><br \
class=""> <a href="https://www.ietf.org/mailman/listinfo/mpls" target="_blank" \
class="">https://www.ietf.org/mailman/listinfo/mpls</a></div> </blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</body>
</html>
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
--===============6531743206878610363==--
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic