Subject: [mpls] Review of draft-rosen-mpls-rfc3107bis

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 2 Aug 2016 17:30:33 +0100

I have done a review of draft-rosen-mpls-rfc3107bis on behalf of the MPLS Review
Team.  

The draft is a candidate for WG adoption and is targeted at obsoleting RFC 3107.

The work proposes a number of clarifications and fixes to RFC 3107 intended to
resolve interoperability issues, and removes an optional feature that does not
appear to have been implemented.

I think that the WG should pounce on this document, adopt it at once, and move
it rapidly to RFC status. It is a classic case of something that can and should
be moved ahead without delay.

There are a few minor things that should be resolved before publication as an
RFC. I do not believe these changes need to be made before adoption.

Thanks,
Adrian

- - - - -

Issues

I think the current text of Section 1 ("Introduction") is really good material
and should be retained. But I don't think it is the right text for an
Introduction
recalling that the document is supposed to stand in its own right without having
to read 3107.

I suggest....

1. Introduction

   This document specifies encodings and procedures for using BGP to
   indicate that a particular router has bound either a single MPLS
   label or a sequence of MPLS labels (organized as a contiguous part of
   an MPLS label stack) ([RFC3031], [RFC3032]) to a particular address
   prefix.  This is done by sending a BGP UPDATE message with its
   Network Layer Reachability Information field set to contain both the 
   prefix and the MPLS labels, and with its Next Hop field identifying 
   the node at which said prefix is bound to said labels.  Each such
   UPDATE also advertises a path to the specified prefix, via the 
   specified next hop.

   This document replaces and obsoletes [RFC3107].  It defines a new BGP
   Capability to be used when binding a sequence of labels to a prefix;
   by using this Capability, the interoperability problems alluded to
   above can be avoided.  This document also removes the unimplemented
   "Advertising Multiple Routes to a Destination" feature, while
   specifying how to use [ADD-PATHS] to provide the same functionality.
   This document also addresses the issue of the how UPDATEs that bind
   labels to a given prefix interact with UPDATEs that advertise paths
   to that prefix but do not bind labels to it.  However, for backwards
   compatibility, it declares most of these interactions to be matters
   of local policy.

   It is believed that implementations that conform to this document 
   will interoperate correctly with existing deployed implementations
   of [RFC3107].

1.1. Changes from RFC 3107

   This document obsoletes RFC 3107 [RFC3107] that previously specified
   this function.

   Although there are many implementations and deployments of RFC 3107,
   there are a number of issues with that document that have impeded
   interoperability in the past, and may potentially impede
   interoperability in the future.

   This document updates the text of RFC 3107 to address the following
   issues:

    .... and then include the bullet list from the existing text

1.2. Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   [RFC2119].

---

There are then too many (i.e., GT.0) references to 3107 in the rest of
the document. Again, the intention is that the document replaces 3107
and stands alone, so backward references to the obsoleted specification
should not exist except in the preamble (above).

I suggest moving such references to the bullet list in 1.1 together
with a description of the problem addressed, and then leaving the 
remaining text as a stand-alone description of the function/process.

I see:
2.1
2.2 twice
2.4 twice

---

Nits

The use of the first person plural in Section 8 sounds a little regal.

idnits shows that a few references have moved on.

---

From: Mach Chen <[email-masked]>
Date: Wed, 3 Aug 2016 08:51:32 +0000

Hi all,

I have done my MPLS-RT review of draft-rosen-mpls-rfc307bis-00. 

The draft is coherent and useful, it's ready for WG adoption.

The draft is well written and I have only one comment regarding to Section 5. IMHO, although it's informational, the description about the relationship between SAFI-1 and SAFI-4 routes should not belong to this document, it's a more common description that is not specific to this label binding process. I'd suggest to remove this section if there is no any other reasons.

Best regards,
Mach

---

From: Eric C Rosen <[email-masked]>
Date: Wed, 17 Aug 2016 11:59:52 -0400

Hi Mach,

Thanks for your review.

On 8/3/2016 4:51 AM, Mach Chen wrote:
> I have only one comment regarding to Section 5. IMHO, although it's informational, the description about the relationship between SAFI-1 and SAFI-4 routes should not belong to this document, it's a more common description that is not specific to this label binding process. I'd suggest to remove this section if there is no any other reasons.

Differing interpretations about the relationship between SAFI-1 and 
SAFI-4 are a very common source of interoperability problems among 
implementations of different vendors.  Thus I think it is very useful to 
document this issue and to call attention to some of the differing 
interpretations.  I think this document is an appropriate place for this 
information; even though this information is not about label binding, it 
is about the semantics of SAFI-4.

Eric

---

From: Loa Andersson <[email-masked]>
Date: Wed, 17 Aug 2016 19:36:28 +0200

Eric, et.al., (copied also idr-chairs and idr-list + bess-chairs and
bess-list)

For those of you that are not subscribed to the mpls-list.

- the mpls wg has started the initial steps for working group adoption,
   there are three steps
   -- mpls-rt review (what you see below is the follow-up discussion on
      that review)
   -- IPR poll, will be sent out soon
   -- working group adoption poll (wgap), that poll will be copied to
      the idr and bess. Hopefully we can that shortly.

I'm sending this to mpls, idr and bess working group, since it has
to do where things should be documented.

On 2016-08-17 17:59, Eric C Rosen wrote:
>> I have only one comment regarding to Section 5. IMHO, although it's
>> informational, the description about the relationship between SAFI-1
>> and SAFI-4 routes should not belong to this document, it's a more
>> common description that is not specific to this label binding process.
>> I'd suggest to remove this section if there is no any other reasons.
>

I agree that this needs to be documented! I can accept that it is done
in draft-rosen-mpls-rfc3107bis, but I would like to have all three wg's
agree to this. I see a few alternatives

- we could document this is in draft-rosen-mpls-rfc3107bis; or
- we could write a separate document
- we could find another document where this has a better fit than in
   draft-rosen-mpls-rfc3107bis
- any other suggestion

Let us know if you have an opinion.

Please send your responses to the mpls wg mailing list ([email-masked]).

/Loa
mpls wg-co-chair

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 18 Aug 2016 17:58:41 +0000

Hi Eric, Mach, 

> On Aug 17, 2016, at 11:59 AM, Eric C Rosen <[email-masked]> wrote:
> 
> Hi Mach,
> 
> Thanks for your review.
> 
> Differing interpretations about the relationship between SAFI-1 and SAFI-4 are a very common source of interoperability problems among implementations of different vendors.  Thus I think it is very useful to document this issue and to call attention to some of the differing interpretations.  I think this document is an appropriate place for this information; even though this information is not about label binding, it is about the semantics of SAFI-4.

I agree with Eric. Even though RFC 3107 was an MPLS WG document, I think the document would fit better in IDR. Having said that, I don’t want to start a protracted debate since we probably have enough cross-WG participation ;^) 

Thanks,
Acee 

> 
> Eric
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 18 Aug 2016 19:49:02 +0000

Hi Loa, et al, 

Since I commented on the MPLS-RT review with respect to the IDR-specific
content, there may be some confusion as to where I stand on the ownership
of this draft. I’ve reviewed this document and agree with the approach
described below. I’m convinced we will get the right level cross-WG review
along as we recognize that it does span multiple WGs. I would expect that
we’ll have implementations conforming to the draft in the near future.

Thanks,
Acee

---

From: Mach Chen <[email-masked]>
Date: Fri, 19 Aug 2016 09:09:40 +0000

Hi Eric,

Thanks for your response!

I still do not think that the description of the differing interpretations of the relationship between SAFI-1 and SAFI-4 belongs in this document. However, for practical reasons I can accept that they are documented here.

Best regards,
Mach

> -----Original Message-----
> From: Eric C Rosen [mailto:[email-masked]]
> Sent: Thursday, August 18, 2016 12:00 AM
> To: Mach Chen; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: Review of draft-rosen-mpls-rfc3107bis
> 
> Hi Mach,
> 
> Thanks for your review.
> 
> informational, the description about the relationship between SAFI-1 and SAFI-4
> routes should not belong to this document, it's a more common description
> that is not specific to this label binding process. I'd suggest to remove this
> section if there is no any other reasons.
> 
> information; even though this information is not about label binding, it is about
> the semantics of SAFI-4.
> 
> Eric