Subject: Re: [GROW] Alia Atlas' Yes on draft-ietf-grow-bmp-15: (with COMMENT)

From: John Scudder <[email-masked]>
Date: Wed, 4 Nov 2015 14:52:41 +0900

On Oct 15, 2015, at 4:46 AM, Alia Atlas <[email-masked]> wrote:
> 
> a) In Section 4.2, I see special casing for an "L3VPN Instance Peer". 
> Will the same thing be necessary for an EVPN peer?  Are there other
> future cases to be considered?

This was an interesting question, thanks. On reflection, "L3VPN Instance Peer" is a misnomer, it really means something more like "peers whose context is identified by an RD". Probably we should rename this field; I suggest "RD Instance Peer" and have stubbed this in. Since EVPN and other L3VPN variants are identified by RDs taken from a common namespace, they fit in. We may need to extend the Peer Types to accommodate peers that are neither "global instance" nor RD, see Rob Shakir's earlier comment. Really, you could think of the catenation of the Peer Type and Peer Distinguisher fields as comprising a unique identifier for the peer.

I think for this draft we should fix the name to clarify what the field really means, but not try to extend to other types of peers. That ought to be straightforward enough in an update document if needed.

> b) In Sec 4.4, for the type=0 String, it may be useful to specify that
> the language is unspecified and based on the configuration.  A similar
> description for the other information strings would be useful.  I'm sure
> that Barry could suggest better text.

Barry, since Alia volunteered your services :-) would you be willing to suggest some text, or OK this option?

OLD:
      *  Type = 0: String.  The Information field contains a free-form
         UTF-8 string whose length is given by the "Information Length"
         field.  The value is administratively assigned.  There is no
         requirement to terminate the string with a null (or any other
         particular) character -- the length field gives its
         termination.  If multiple strings are included, their ordering
         MUST be preserved when they are reported.
NEW:
      *  Type = 0: String.  The Information field contains a free-form
         UTF-8 string whose length is given by the "Information Length"
         field.  The value (including the language) is administratively assigned.  There is no
         requirement to terminate the string with a null (or any other
         particular) character -- the length field gives its
         termination.  If multiple strings are included, their ordering
         MUST be preserved when they are reported.

and

OLD:
      *  Type = 0: String.  The Information field contains a free-form
         UTF-8 string whose length is given by the "Information Length"
         field.  Inclusion of this TLV is optional.  It MAY be used to
         provide further detail for any of the defined reasons.
         Multiple String TLVs MAY be included in the message.
NEW:
      *  Type = 0: String.  The Information field contains a free-form
         UTF-8 string whose length is given by the "Information Length"
         field.  The language is unspecified and may be determined by the implementation and/or configuration.
         Inclusion of this TLV is optional.  It MAY be used to
         provide further detail for any of the defined reasons.
         Multiple String TLVs MAY be included in the message.

Thanks,

--John

---

From: Alia Atlas <[email-masked]>
Date: Wed, 4 Nov 2015 02:29:10 -0500

John,

Thanks for addressing my comments.  I'm glad they were helpful.
Your solutions look good to me.

Regards,
Alia

On Wed, Nov 4, 2015 at 12:52 AM, John Scudder <[email-masked]> wrote:

> This was an interesting question, thanks. On reflection, "L3VPN Instance
> Peer" is a misnomer, it really means something more like "peers whose
> context is identified by an RD". Probably we should rename this field; I
> suggest "RD Instance Peer" and have stubbed this in. Since EVPN and other
> L3VPN variants are identified by RDs taken from a common namespace, they
> fit in. We may need to extend the Peer Types to accommodate peers that are
> neither "global instance" nor RD, see Rob Shakir's earlier comment. Really,
> you could think of the catenation of the Peer Type and Peer Distinguisher
> fields as comprising a unique identifier for the peer.
>
> I think for this draft we should fix the name to clarify what the field
> really means, but not try to extend to other types of peers. That ought to
> be straightforward enough in an update document if needed.
>
>          field.  The value *(including the language)* is administratively
> assigned.  There is no
>          field.  *The language is unspecified and may be determined by
> the implementation and/or configuration.*

---

From: "John G. Scudder" <[email-masked]>
Date: Wed, 4 Nov 2015 16:54:29 +0900

> I think for this draft we should fix the name to clarify what the field really means, but not try to extend to other types of peers. That ought to be straightforward enough in an update document if…

By the way, this made me realize we actually hadn't defined a registry for Peer Types, oops. I will go ahead and add one, along with one for Peer Flags for good measure.

--John