Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt

[t.petch <[e-mail]>]

<snipping the agreed parts>

Tom Petch

----- Original Message -----
From: "Job Snijders" <[e-mail]>
To: "t.petch" <[e-mail]>
Cc: <[e-mail]>
Sent: Monday, October 03, 2016 12:57 PM


> Dear Tom,
>
> On Mon, Oct 03, 2016 at 12:06:53PM +0100, t.petch wrote:
>
> > > > On more challenging matters, I think s.2 should specify the
encoding
> > > > of a 16-bit ASN - left or right justified?
> > >
> > > I am not sure that is required. Technically speaking, all ASNs are
now
> > > 32-bit ASNs.
> >
> > Well, not in traditional communities so if anyone 'knows' that the
> > first 16 bit are an ASN, they will be disappointed, so I think it
> > worth spelling out.
>
> I am not convinced, it does feel somewhat superfluous to me. Section 2
> clearly depicts an ascii art with 32 bits for the Global
Administrator.
>
> We could add something which is akin to what rfc4893 states:
>
>     "For Autonomous System numbers which can be encoded as a 2-octet
>     value, the two high-order octets of the Global Administrator field
>     are set to zero."
>
> Do you have a better suggested sentence? The above feels like a
kludge.
>

I think that that text is fine.

Tom Petch


<snip>
>
>
> > > > More generally, a big issue with 4 octet ASN was migration, the
> > > > world becoming a mix of boxes that supported 4 octet ASN and
those
> > > > that did not.  I think that that issue needs addressing.  Will
> > > > boxes convert traditional communities to large, or should that
be
> > > > specifically prohibited (I think that latter)?
> > >
> > > I consider the topic of 'mapping' out of scope for an IDR
document. See
> > > my earlier message here:
https://mailarchive.ietf.org/arch/msg/idr/GHxOF9Y6wsdQ2e_-4jI2ejUZ2kk
> > >
> > > Mapping is up to the operator's local routing policy and by
extend, the
> > > vendors.
> >
> > Well, Bertrand Duvivier seemed to be proposing something along these
> > lines last week, and I for one would see a mapping from old protocol
> > to new protocol as very much is scope for the new protocol I-D, if
> > only to say there is none.
>
> I am really not sure we should specify everything the document is
_not_.
> (Similar to your agreement to remove the sentence about 'no routing
> semantics are implied') I also do not see precedent for 'there is no
> mapping between 1997 and extended communities' in the rfc4360
document.
>
> I agree that mapping in and of itself is an interesting challenge, but
> the concept is probably is better served as an internet-draft
targetted
> to be of Informational status in the GROW working group.
>
> Kind regards,
>
> Job