Re: [mpls] New Version Notification for draft-mirsky-mpls-p2mp-bfd-07.txt

["Carlos Pignataro (cpignata)" <[e-mail]>]

Dear Greg,


On Jun 11, 2019, at 1:26 AM, [e-mail]<mailto:[e-mail]> wrote:


Dear Carlos,

thank you for your comments. Please find my answers and notes in-line tagged GIM>>.

You are welcome — please find my follow-ups inline.


Regards,

Greg Mirsky


Hello,

I’ve not looked at this whole document, but this email triggered me to check the encapsulation of BFD. So, while not commenting on the value of this document, I do have two questions: one on the encapsulation, one on the proposed new TLV.

The IP BFD encapsulation described here is the same for p2p and for multipoint, based on RFC 8562 and Section 3.1 of this doc, using destination UDP port 3784.

However, Section 3.2 requests a new G-ACh Channel Type (see Section 3.1) for “Multipoint BFD Session”, different than BFD over G-ACh as per RFC 5885.
GIM>> If BFD control packet transmitted over MPLS LSP, whether p2p or p2mp, using IP/UDP encapsulation, then it may be achieved without the use of any G-ACh. Over a PW, BFD control packet in IP/UDP encapsulation can be transmitted using ACH type 0x0021 (IPv4) or 0x0057 (IPv6). The new G-ACh is proposed for the scenario when a BFD control packet for p2mp BFD session to be transmitted without IP/UDP encapsulation, in so-called PW-ACH encapsulation (without IP/UDP Headers).

I understand what you write, but it does not answer my question.

What are the technical reasons for your document to request a new “Multipoint BFD Session” code point and not use:
    0x0007  BFD Control, PW-ACH encapsulation (without IP/UDP Headers)


 Will clarify the description in the IANA Considerations section.

Why this difference? What is the reason to have to differentiate with a new Channel Type?
GIM>> The reason is that RFC 8562 changes how the tail demultiplexes BFD control packet. Because the Your Discriminator field in BFD control packet received by a tail will always be 0, RFC 8562 defined:
   IP and MPLS multipoint tails MUST demultiplex BFD packets based on a
   combination of the source address, My Discriminator, and the identity
   of the multipoint path that the multipoint BFD Control packet was
   received from.  Together they uniquely identify the head of the
   multipoint path.

Again, if you use the same code point for IP encapsulation for p2p and mp. Why does non-IP use different ones?
Why not use 0x0007 for this document’s non-IP encapsulation?

The new G-ACh type is to indicate that TLV that carries the source address immediately follows the BFD control packet.
   Also, the “CC/CV MEP-ID TLV” is specified in RFC 6428, which is scoped to MPLS-TP. See also the scope in RFC 7276, defining usage of BFD in MPLS-TP. How is that proposed to be used for MPLS?
   GIM>> Thank you for catching it. References to "MEP ID" are unnecessary and will be removed in the next version.


The real question is: What is this document defining really? What specific behavior needs specifying?

Best,

Carlos.


Best,

Carlos.

On Jun 5, 2019, at 4:40 PM, Greg Mirsky <[e-mail]<mailto:[e-mail]><mailto:[e-mail]>> wrote:

Dear All,
the new version includes updates:

  *   request for the allocation of a new G-ACh type "Multipoint BFD Session"
  *   an extended explanation for the use of non-IP encapsulation of BFD control packet in multipoint BFD session over MPLS LSP
  *   updated references to RFC 8562 BFD for Multipoint Networks

Hope it helps to get WG AP decision.

Regards,
Greg

---------- Forwarded message ---------
From: <[e-mail]<mailto:[e-mail]><mailto:[e-mail]>>
Date: Tue, Jun 4, 2019 at 6:19 PM
Subject: New Version Notification for draft-mirsky-mpls-p2mp-bfd-07.txt
To: Gregory Mirsky <[e-mail]<mailto:[e-mail]><mailto:[e-mail]>>



A new version of I-D, draft-mirsky-mpls-p2mp-bfd-07.txt
has been successfully submitted by Greg Mirsky and posted to the
IETF repository.

Name:           draft-mirsky-mpls-p2mp-bfd
Revision:       07
Title:          BFD for Multipoint Networks over Point-to-Multi-Point MPLS LSP
Document date:  2019-06-04
Group:          mpls
Pages:          8
URL:            https://www.ietf.org/internet-drafts/draft-mirsky-mpls-p2mp-bfd-07.txtStatus:         https://datatracker.ietf.org/doc/draft-mirsky-mpls-p2mp-bfd/Htmlized:       https://tools.ietf.org/html/draft-mirsky-mpls-p2mp-bfd-07Htmlized:       https://datatracker.ietf.org/doc/html/draft-mirsky-mpls-p2mp-bfdDiff:           https://www.ietf.org/rfcdiff?url2=draft-mirsky-mpls-p2mp-bfd-07Abstract:
   This document describes procedures for using Bidirectional Forwarding
   Detection (BFD) for multipoint networks to detect data plane failures
   in Multiprotocol Label Switching (MPLS) point-to-multipoint (p2mp)
   Label Switched Paths (LSPs).  It also describes the applicability of
   LSP Ping, as in-band, and the control plane, as out-band, solutions
   to bootstrap a BFD session in this environment.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org/><http://tools.ietf.org%3Chttp//tools.ietf.org/%3E.>;.

The IETF Secretariat

_______________________________________________
mpls mailing list
[e-mail]<mailto:[e-mail]><mailto:[e-mail]>https://www.ietf.org/mailman/listinfo/mpls