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

Hi Nobo,
greatly appreciate your review and thoughtful comments. I'll send another note to propose resolutions by next week (digging out of two-weeks of e-mail).

	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).

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.

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.

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.

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