Re: [mpls] Alexey Melnikov's Discuss on draft-ietf-mpls-rfc3107bis-02: (with DISCUSS and COMMENT)

[Alexey Melnikov <[e-mail]>]

Hi Acee,

On Thu, Aug 17, 2017, at 02:11 PM, Acee Lindem (acee) wrote:
> Hi Alexey,
> 
> See one comment below.
> 
> On 8/17/17, 8:05 AM, "mpls on behalf of Alexey Melnikov"
> <[e-mail] on behalf of [e-mail]> wrote:
> 
> >Hi Eric,
> >Sorry for the slow response.
> >
> >On Tue, Aug 1, 2017, at 09:59 PM, Eric C Rosen wrote:
> >> 
> >> > DISCUSS:
> >> > ----------------------------------------------------------------------
> >> >
> >> > I would like to discuss one issue before recommending approval of
> >>this document:
> >> >
> >> > In Section 2.1:
> >> >
> >> >     The value field of the Multiple Labels Capability (shown in
> >>Figure 1)
> >> >     consists of one or more triples, where each triple consists of
> >>four
> >> >     octets.  The first two octets of a triple specify an AFI value,
> >>the
> >> >     third octet specifies a SAFI value, and the fourth specifies a
> >>Count.
> >> >     If one of the triples is <AFI,SAFI,Count>, the Count is the
> >>maximum
> >> >     number of labels that the BGP speaker sending the Capability can
> >> >     process in a received UPDATE of the specified AFI/SAFI.
> >> >
> >> > I think lack of recommendations on the minimal supported Count value
> >>will
> >> > result in lack of interoperability. What are the common Count values
> >>used by
> >> > implementations?
> >> 
> >> An implementation is not required to support more than one label in the
> >> NLRI.  In that case, of course the Multiple Labels Capability is not
> >> supposed to be used.  So if the Capability is used, the minimum value
> >>is 
> >> 2.   It looks like the document does not state that explicitly, but it
> >> certainly should.  I will fix that.
> >> 
> >> Thus the literal answer to your question is that the Multiple Labels
> >> Capability MUST NOT contain a count less than 2.
> >> 
> >> Typically when SAFI-4 or SAFI-128 routes are used, only one label is
> >> included.  If an operator has a scenario in which multiple labels are
> >> needed, it is necessary for the operator to ensure that all his vendors
> >> can support however many labels he needs.  That's not really something
> >> that the standard can address.
> >
> >The standard can specify minimum requirement (and this has been done in
> >the past). For example you can say that all implementations must support
> >4 (or whatever).
> >
> >> If the operator needs 3 labels in the
> >> NLRI, it won't help much if some of his boxes can only support 2.
> >
> >Exactly my point. Without the minimum you still need to have out-of-band
> >selection of implementations that support your minimum requirements.
> >
> >> ---------------------------------------------------------------------
> >> > COMMENT:
> >> > ----------------------------------------------------------------------
> >> >
> >> > In Section 2.3:
> >> >
> >> >        0                   1                   2                     3
> >> >        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >> >       +-+-+-+-+-+-+-+-+
> >> >       |    Length     |
> >> >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> >       |                 Label                 |Rsrv |S~
> >> >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> >       ~                 Label                 |Rsrv |S|
> >> >       
> >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> >       |                          Prefix
> >>~
> >> >       ~       
> >>|
> >> >       
> >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> >
> >> >                      Figure 3: NLRI With Multiple Labels
> >> >
> >> >     - Length:
> >> >
> >> >        The Length field consists of a single octet.  It specifies the
> >> >        length in bits of the remainder of the NLRI field.
> >> >
> >> > I would like to double check that my math is correct. With SAFI=128
> >>and AFI=2,
> >> > assuming the prefix length of 192 bits, this will leave space for:
> >> >
> >> >   (255-192)/24 = 2.625. So this configuration only allows for 2
> >>labels to be included, right?
> >> >
> >> Your arithmetic is accurate ;-)
> >> 
> >> If you are implying that this is not necessarily the best mechanism for
> >> associating an arbitrarily long label stack with a prefix, I wouldn't
> >> disagree.
> >
> >Yes, I was just surprised that this has such a small limit. I wanted to
> >make sure that this is by design.
> 
> Note that there are more complex BGP encodings in IDR WG documents that
> support larger label stacks.
> 
> https://www.ietf.org/id/draft-ietf-idr-segment-routing-te-policy-00.txt
> https://www.ietf.org/id/draft-ietf-idr-tunnel-encaps-07.txt
> 
> This much-needed document simply clears up the ambiguities of advertising
> multiple labels with the RFC 3107 NLRI encodings.

So just to double check: you are saying that this is cleaning up a
legacy specification and there are better/more modern specifications
that can do the same thing?