Re: [mpls] working group last call for draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf

Hi Nobo,
finally got to address your comments (greatly appreciate your help).
Please find in-line and tagged GIM>>.

	Kind regards,
		Greg

-----Original Message-----
From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Nobo Akiya
Sent: Sunday, April 05, 2015 6:10 PM
To: 'Ross Callon'; mpls@ietf.org
Cc: mpls-chairs@tools.ietf.org; draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf@tools.ietf.org
Subject: Re: [mpls] working group last call for draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf

Hi Ross,

My apologies for being late.

I skipped over all the PM details, but read rest of the document. This document defines an important functionality for TP OAM, and I do support its progress.

I did spot few things which should be addressed in the document (especially
#1 and #4).

1. Section 2.2

      - BFD Configuration sub-TLV, which MUST be included if either the
      CC, the CV or both OAM Function flags being set in the OAM
      Function Flags Sub-TLV [RFC7260].

I'm guessing that above is a copy & paste error/leftover. MPLS OAM Function TLV is defined in the section 2.2 of the draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf document, and the TLV has MPLS OAM TLV Flags defined. We would want to refer to the MPLS OAM TLV Flags in the MPLS OAM Function TLV instead of OAM Function flags in the OAM Function Flags Sub-TLV defined in RFC7260.

And if above is true (and the text is corrected), then the reference to
RFC7260 can also be removed (as it is not mentioned anywhere else in this document).

GIM>> Indeed, cut-paste. New text will be:
      - BFD Configuration sub-TLV, which MUST be included if either the
      CC, the CV or both MPLS OAM Function flags being set in the MPLS
      OAM Functions TLV .
And the Table 1 caption will be not to MPLS OAM TLV Flags but to  MPLS OAM Functions Flags.

2. Section 2.2

      This sub-TLV MUST carry a "BFD
      Local Discriminator sub-TLV" and a "Timer Negotiation Parameters
      sub-TLV" if the N flag is cleared.  The "Source MEP-ID sub-TLV"
      MUST also be included.  If the I flag is set, the "BFD
      Authentication sub-TLV" MAY be included.

I think above should be removed, as it is a subset (and a bit confusion
subset) of what is better described at the end of Section 2.2.1 anyways.

GIM>> Agree to remove.

3. Section 2.2.1

         In this case an updated
         Negotiation Timer Parameters sub-TLV, containing values
         supported by the egress node, is returned to the ingress.

Above is probably a good place to reference RFC7419 to prevent problematic interop of multiple devices.

GIM>> Agreed. Updated with the reference:
         - the N flag is cleared and the S flag is set, and the
         Negotiation Timer Parameters sub-TLV received by the egress
         contains unsupported values.  In this case an updated
         Negotiation Timer Parameters sub-TLV, containing values
         supported by the egress node [RFC7419], is returned to the
         ingress.

4. Section 2.2.4

There needs to be some synchronicity between AuthType/AuthKeyID to specified in "this" MPLS echo request message and AuthType/AuthKeyID being used by BFD control packets. For example:

- If BFD control packets using "new" auth is received by the egress LSR before MPLS echo request with new "auth" is received, all BFD control packets using "new" auth will be dropped.
- To take that a step further, if BFD control packets using "new" auth is received by the egress LSR before "this" MPLS echo request is received by the egress LSR and corresponding BFD session is updated to point to the "new" auth , all BFD control packets using "new" auth will be dropped.
- If BFD control packets using "new" auth is only sent X time after sending the MPLS echo request with new "auth", then it is not guaranteed that the egress LSR will still be accepting BFD control packets with "old" auth for X amount of time.
- And of course there's the error case of the egress LSR not being able to support the specified the "new" auth specified in received MPLS echo request, but the ingress LSR starts using the "new" auth before it receives back NOSUP from the egress LSR via MPLS echo reply.

I suspect if sufficient details are not defined, we would likely run into some inter-op issues with this aspect.

GIM>> I agree, more details should be provided. How about a new paragraph added to the section:
   If BFD Authentication sub-TLV used for a BFD session in Up state then
   the Sender of the MPLS LSP Echo Request SHOULD ensure that old and
   new modes of authentication, i.e. combination of Auth.Type and Auth.
   Key ID, used to send and receive BFD control packets until the
   Sender can confirm that its peer had switched to the new
   authentication.

Thanks!

-Nobo

> -----Original Message-----
> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
> Sent: April-05-15 5:10 PM
> To: mpls@ietf.org
> Cc: Ross Callon; mpls-chairs@tools.ietf.org;
draft-ietf-mpls-lsp-ping-mpls-tp-
> oam-conf@tools.ietf.org
> Subject: Re: [mpls] working group last call for
draft-ietf-mpls-lsp-ping-mpls-tp-
> oam-conf
> 
> This working group last call has now ended.
> 
> There was one public response (to the MPLS working group) in support. 
> I
also
> got private responses of support from two of the authors. Otherwise 
> there
were
> no responses (neither in favor nor opposed). This is not sufficient to
constitute
> "rough consensus". As such the working group last call has failed.
> 
> My inclination is to wait for the July IETF (in Prague), and give the
authors an
> opportunity to present and solicit additional support. Depending upon 
> the response there, we may then repeat the WGLC.
> 
> Thanks, Ross
> (as WG co-chair)
> 
> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
> Sent: Tuesday, March 10, 2015 4:46 PM
> To: mpls@ietf.org
> Cc: mpls-chairs@tools.ietf.org; draft-ietf-mpls-lsp-ping-mpls-tp-oam-
> conf@tools.ietf.org
> Subject: [mpls] working group last call for
draft-ietf-mpls-lsp-ping-mpls-tp-oam-
> conf
> 
> Working Group,
> 
> This is to initiate a working group last call on
draft-ietf-mpls-lsp-ping-mpls-tp-
> oam-conf-09.
> Because this WGLC will span the IETF in Dallas, it will be extended to
just over
> three weeks.
> 
> Please send your comments to the mpls wg mailing list (mpls@ietf.org).
> 
> There are no IPR disclosures against this document. All the authors 
> have
stated
> that they
> are not aware of any IPR that relates to this draft (two of the 
> responses
were
> private to
> the WG chairs).
> 
> This working group last call ends Thursday  April 2, 2015.
> 
> Ross
> for the MPLS WG chairs
> 
> 

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