Subject: Re: [Isis-wg] [Technical Errata Reported] RFC4920 (4480)

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 25 Sep 2015 13:15:49 +0100

All,

This email is copied to TEAS and ISIS, but it would be really helpful if any
discussion was held to one list. CCAMP is probably best because they "own" RFC
4920.

The CCAMP chairs asked me to look into this as one of the original authors, and
I have to say it has been so long that I can't recall the answer.

However, I looked at RFC 1195 and found section 3.3 gave me that the full
description of an Area ID as:
 
>         AFI       1 octet       value "47" (specifies ICD format)
> 
>         ICD       2 octet       value "00 05" (specifies Internet/Gosip)
> 
>         DFI       1 octet       value "xx"
> 
>         AA        3 octets      value "xx xx xx" (specifies special
>                                 IP-only use of NSAPs)
> 
>         Reserved  2 octets      must be "00 00"
> 
>         RD        2 octets      contains autonomous system number
> 
>         Area      2 octets      must be assigned as described below
 
This implies (to me) that an Area ID must be at least the trailing two octets,
but may be given more context reading up this table up to a maximum of 13
octets.

All I deduce from this is that I am consistent in my ability to reproduce my
processing, not that I am right.

Can someone with IS-IS clue please comment:
What are the max and min string lengths of an "area ID" in IS-IS?

Thanks,
Adrian

> -----Original Message-----
> From: RFC Errata System [mailto:[email-masked]]
> Sent: 21 September 2015 06:55
> To: [email-masked]; [email-masked]; [email-masked]; n-
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: [Technical Errata Reported] RFC4920 (4480)
> 
> The following errata report has been submitted for RFC4920,
> "Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=4920&eid=4480
> 
> --------------------------------------
> Type: Technical
> Reported by: Dhruv Dhody <[email-masked]>
> 
> Section: 6.2
> 
> Original Text
> -------------
> For types 10 and 23, the Value field has the format:
> 
>        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      |     IS-IS Area Identifier                     |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       ~                     IS-IS Area Identifier (continued)         ~
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>        Length
> 
>           Length of the actual (non-padded) IS-IS Area Identifier in
>           octets.  Valid values are from 2 to 11 inclusive.
> 
> Corrected Text
> --------------
> For types 10 and 23, the Value field has the format:
> 
>        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      |     IS-IS Area Identifier                     |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       ~                     IS-IS Area Identifier (continued)         ~
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>        Length
> 
>           Length of the actual (non-padded) IS-IS Area Identifier in
>           octets.  Valid values are from 1 to 13 inclusive.
> 
> Notes
> -----
> IS-IS area IDs can vary from 1 to 13 bytes in length (max NSAP length is 20,
minus
> 1 byte for NSEL, minus 6 bytes for SysID).
> 
> *Noted by Jonathan Hardwick in another document that was using the same
> data.
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary.
> 
> --------------------------------------
> RFC4920 (draft-ietf-ccamp-crankback-06)
> --------------------------------------
> Title               : Crankback Signaling Extensions for MPLS and GMPLS
RSVP-TE
> Publication Date    : July 2007
> Author(s)           : A. Farrel, Ed., A. Satyanarayana, A. Iwata, N. Fujita,
G. Ash
> Category            : PROPOSED STANDARD
> Source              : Common Control and Measurement Plane
> Area                : Routing
> Stream              : IETF
> Verifying Party     : IESG

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 25 Sep 2015 14:15:16 +0000

Adrian -

The definitive document on OSI addressing is ISO 8348 (Annex A and B). Freely available here: http://standards.iso.org/ittf/PubliclyAvailableStandards/c035872_ISO_IEC_8348_2002(E).zip

Some text in ISO 10589 Section 7.1 is also helpful.

But if you don't want to wade through the documents (for which I would not blame you :-) ) here's the short version: An area address is 1 - 13 octets in length - so at a quick read the proposed text in the errata seems to be correct.

   Les

> From: Isis-wg [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Friday, September 25, 2015 5:16 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Isis-wg] [Technical Errata Reported] RFC4920 (4480)
> 
> All,
> 
> discussion was held to one list. CCAMP is probably best because they "own"
> RFC 4920.
> 
> The CCAMP chairs asked me to look into this as one of the original authors,
> and I have to say it has been so long that I can't recall the answer.
> 
> > The following errata report has been submitted for RFC4920, "Crankback
> > Signaling Extensions for MPLS and GMPLS RSVP-TE".
> >
> > *Noted by Jonathan Hardwick in another document that was using the
> > same data.
> >
> > Instructions:
> > -------------
> > use "Reply All" to discuss whether it should be verified or rejected.
> > When a decision is reached, the verifying party (IESG) can log in to
> > change the status and edit the report, if necessary.
> >
> _______________________________________________
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 25 Sep 2015 20:43:26 +0100

OK, Thanks Les, a great help.

One last point of clarification...

When RFC 1195 says...
>         Area      2 octets      must be assigned as described below
... why am I confused that that is allowed to be just one octet?

Cheers,
Adrian

> From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
> Sent: 25 September 2015 15:15
> To: [email-masked]; [email-masked]
> Subject: RE: [Isis-wg] [Technical Errata Reported] RFC4920 (4480)
> 
> Adrian -
> 
> The definitive document on OSI addressing is ISO 8348 (Annex A and B). Freely
> available here:
> http://standards.iso.org/ittf/PubliclyAvailableStandards/c035872_ISO_IEC_8348_
> 2002(E).zip
> 
> But if you don't want to wade through the documents (for which I would not
> blame you :-) ) here's the short version: An area address is 1 - 13 octets in
length -
> so at a quick read the proposed text in the errata seems to be correct.
> 
>    Les
> 
> 
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 25 Sep 2015 20:06:55 +0000

Adrian -

I assume you are quoting Section 3.3?

NSAPs come in a variety of flavors/formats depending upon the addressing authority. The example in RFC Section 3.3 is talking about using USA GOSIP version 2.0 format as specified in Reference #9. The NSAP field is then broken into a set of subfields which include:

        DFI       1 octet       value "xx"

        ID        6 octets      must be assigned as desribed below

        SEL       1 octet       used as described below

Everything up to "ID" is part of the "area address". So the AFI/ICD/AA/Reserved/RD/Area comprise a 13 octet "area address" - part of which are specific values mandated by the GOSIP format. The "area" is simply one field in this GOSIP format.

ISO 8348 has more info - but frankly I always found this somewhat nauseating to read. The simplest way of thinking about things is:

Area Address: 1 -13 octets (length and values depend on the NSAP format chosen)
System ID: 1-6 octets - but always 6 octets in practice
NSEL: 1 octet - always 0

   Les

> Sent: Friday, September 25, 2015 12:43 PM
> To: Les Ginsberg (ginsberg); [email-masked]
> > The definitive document on OSI addressing is ISO 8348 (Annex A and B).
> > Freely available here:
> > But if you don't want to wade through the documents (for which I would
> > not blame you :-) ) here's the short version: An area address is 1 -
> > 13 octets in
> length -
> > > This email is copied to TEAS and ISIS, but it would be really
> > > helpful if any discussion was held to one list. CCAMP is probably best
> because they "own"
> > > RFC 4920.
> > >
> > > The CCAMP chairs asked me to look into this as one of the original
> > > authors, and I have to say it has been so long that I can't recall the
> answer.
> > >
> > > However, I looked at RFC 1195 and found section 3.3 gave me that the
> > > full description of an Area ID as:
> > >
> > > This implies (to me) that an Area ID must be at least the trailing
> > > two
> octets,
> > > but may be given more context reading up this table up to a maximum
> > > of 13 octets.
> > >
> > > All I deduce from this is that I am consistent in my ability to
> > > reproduce my processing, not that I am right.
> > >
> > > > To: [email-masked]; [email-masked];
> > > > [email-masked]; n- [email-masked];
> > > > [email-masked]; [email-masked]; [email-masked];
> > > > [email-masked]; [email-masked];
> > > > [email-masked]
> > > > This erratum is currently posted as "Reported". If necessary,
> > > > please use "Reply All" to discuss whether it should be verified or
> rejected.
> > > > When a decision is reached, the verifying party (IESG) can log in
> > > > to change the status and edit the report, if necessary.
> > > >

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 25 Sep 2015 22:10:04 +0100

Got it. Thanks!

CCAMP chairs - looks like the Errata Report is correct.

Adrian

> Sent: 25 September 2015 21:07
> NSAPs come in a variety of flavors/formats depending upon the addressing
> authority. The example in RFC Section 3.3 is talking about using USA GOSIP
> version 2.0 format as specified in Reference #9. The NSAP field is then broken
> into a set of subfields which include:
> 
> Everything up to "ID" is part of the "area address". So the
> AFI/ICD/AA/Reserved/RD/Area comprise a 13 octet "area address" - part of
> which are specific values mandated by the GOSIP format. The "area" is simply
> one field in this GOSIP format.
> 
> ISO 8348 has more info - but frankly I always found this somewhat nauseating
to
> read. The simplest way of thinking about things is:
>

---

From: Daniele Ceccarelli <[email-masked]>
Date: Sat, 26 Sep 2015 14:42:46 +0000

Thanks a lot Les and Adrian.

BR
Daniele

> From: Teas [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: venerdì 25 settembre 2015 23:10
> To: 'Les Ginsberg (ginsberg)'; [email-masked]
> Subject: Re: [Teas] [Isis-wg] [Technical Errata Reported] RFC4920 (4480)
> 
> Got it. Thanks!
> 
> > NSAPs come in a variety of flavors/formats depending upon the
> > addressing authority. The example in RFC Section 3.3 is talking about
> > using USA GOSIP version 2.0 format as specified in Reference #9. The
> > NSAP field is then broken into a set of subfields which include:
> >
> > AFI/ICD/AA/Reserved/RD/Area comprise a 13 octet "area address" - part
> > of which are specific values mandated by the GOSIP format. The "area"
> > is simply one field in this GOSIP format.
> >
> > Area Address: 1 -13 octets (length and values depend on the NSAP
> > format
> > chosen)
> > > > http://standards.iso.org/ittf/PubliclyAvailableStandards/c035872_I
> > > > SO_I
> > > > EC_8348_
> > > > 2002(E).zip
> > > >
> > > > But if you don't want to wade through the documents (for which I
> > > > would not blame you :-) ) here's the short version: An area
> > > > address is 1 -
> > > > 13 octets in
> > > length -
> > > > > The CCAMP chairs asked me to look into this as one of the
> > > > > original authors, and I have to say it has been so long that I
> > > > > can't recall the
> > > answer.
> > > > >
> > > > > However, I looked at RFC 1195 and found section 3.3 gave me that
> > > > > the full description of an Area ID as:
> > > > >
> > > > > This implies (to me) that an Area ID must be at least the
> > > > > trailing two
> > > octets,
> > > > > but may be given more context reading up this table up to a
> > > > > maximum of 13 octets.
> > > > >
> > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> > > > > > +-
> > > +
> > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> > > > > > +-
> > > +
> > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> > > > > > +-
> > > +
> > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> > > > > > +-
> > > +
> > > > > > *Noted by Jonathan Hardwick in another document that was using
> > > > > > the same data.
> > > > > >
> > > > > > Instructions:
> > > > > > -------------
> > > > > > When a decision is reached, the verifying party (IESG) can log
> > > > > > in to change the status and edit the report, if necessary.
> > > > > >
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas