Subject: Re: [mpls] MPLS-RT review of draft-osborne-mpls-extended-admin-groups-01

From: "Daniel King" <[email-masked]>
Date: Mon, 3 Jun 2013 19:12:41 +0900

Hi All, 

As a member of the MPLS-RT, I was asked to the review the following
document: 

Extended Administrative Groups in MPLS-TE
http://tools.ietf.org/html/draft-osborne-mpls-extended-admin-groups-01

The I-D looks to add a sub-TLV (IGP-TE) to provide for additional
administrative groups (AGs). The requirement is derived from the current
limit of 32 AGs. To extend beyond the 32 AG limit (Extended AGs - EAGs), the
I-D  proposes an OSPF/ISIS (TE) sub-TLV and an RSVP C-Type (Class 207).

Overall the draft is well-written and the solution proposal has been
documented. I think the document should be considered for WG adoption. 

A few areas that will require further discussion include: backwards
compatibility, advertising default values, and a few NITS. 

1. Backwards Compatibility
Within the network of nodes that support EAG and those that do not. Given
that AGs may already be widely used within the network. The author proposes
that if a node is advertising both the AG and EAG, then the first 32 bits of
the EAG must be identical to the advertised AG. Thus allowing the continued
use of AGs, even if nodes in the network are incapable of supporting EAGs.
This seems logical, but should be discussed and approved by users
(operators). 

2. Advertising Default Values
The I-D proposes that specified but not unadvertised EAG have a default
value of 0. This may differ from other vendor implementations of how they
treat unadvertised AGs. Further discussion would be required with vendors
who implemented AGs, and might be interested in implementing EAGs.   

Various NITs/suggestions:

3. There are a number of TBD ("To Be Discussed") and Editor Notes that need
to be either discussed, but in some cases just updated or removed. 

4. Use of Requirements Language should be checked, specifically uses of
"must", "shouldn't". 

5. Documenting Procedures and Error Handling. Although the I-D documents
what seems to be the necessary procedures in various scenarios, it may be
helpful (readability) to specifically highlight them in a procedures section
or sub-section.   

6. Maybe a paragraph or short sub-section providing motivation and context
would be helpful to the reader (i.e., why are 32 colors not sufficient for
today's networks?).

Br, Dan. 

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]] 
Sent: 18 May 2013 19:51
To: Daniel King; Mach Chen; [email-masked]; Curtis Villamizar
Cc: [email-masked];
[email-masked]; VIGOUREUX, MARTIN
(MARTIN)
Subject: MPLS-RT review of draft-osborne-mpls-extended-admin-groups-01

Dan, Mach, Nic and Curtis,

You have been selected as MPLS Review team reviewers for
draft-osborne-mpls-extended-admin-groups-01.

Note to authors: You have been CC'd on this email so that you can know that
this review is going on. However, please do not review your own document.

Reviews should comment on whether the document is coherent, is it useful
(ie, is it likely to be actually useful in operational networks), and is the
document technically sound?  We are interested in knowing whether the
document is ready to be considered for WG adoption (ie, it doesn't have to
be perfect at this point, but should be a good start).

Reviews should be sent to the document authors, WG co-chairs and WG
secretary, and CC'd to the MPLS WG email list. If necessary, comments may be
sent privately to only the WG chairs.

Are you able to review this draft by June 3, 2013?

Thanks, Loa
(as MPLS WG chair)

-- 

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

---

From: "Daniel King" <[email-masked]>
Date: Mon, 3 Jun 2013 20:27:56 +0900

Update!

After having a Skype chat, we think the answer to the RBNF question is:

<Path Message> ::= 	<Common Header> [ <INTEGRITY> ]
			<SESSION> <RSVP_HOP>
                            		<TIME_VALUES>
			[ <EXPLICIT_ROUTE> ]
			<LABEL_REQUEST>
			[ <SESSION_ATTRIBUTE_RA> 
			[ <EXTENDED_SESSION_ATTRIBUTE_RA> ]

Br, Dan. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Daniel King
Sent: 03 June 2013 19:13
To: 'Loa Andersson'; 'Mach Chen'; [email-masked]; 'Curtis Villamizar'
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: Re: [mpls] MPLS-RT review of
draft-osborne-mpls-extended-admin-groups-01

Hi All, 

Br, Dan. 

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]]
Sent: 18 May 2013 19:51
To: Daniel King; Mach Chen; [email-masked]; Curtis Villamizar
Cc: [email-masked];

Thanks, Loa
(as MPLS WG chair)

-- 

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

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Mon, 3 Jun 2013 13:05:01 +0000

Hi Daniel-

  Thanks for your comments.  My replies are inline.

> Sent: Monday, June 03, 2013 6:13 AM
> Cc: [email-masked]; [email-masked]; draft-osborne-mpls-
> [email-masked]
> Subject: Re: [mpls] MPLS-RT review of draft-osborne-mpls-extended-admin-
> groups-01
> 
> Hi All,
> 

EO#  I agree that discussion is necesary and I welcome it. 
For what it's worth, my first aproach to this (the -00 draft) did it the other way around, starting the EAG numbering at bit 32.  This is the only other approach I can see, and it's much uglier.

> who implemented AGs, and might be interested in implementing EAGs.

EO#  Agreed.  This isn't a new problem, though; the base TE specs have the same issue.  The current admin group sub-TLV is optional and there's no text that describes what to do if it's not there.  Is it possible to address this question only for EAG and not AG?  I am nervous about providing new rules for AG since that may introduce big backward compatability questions.

> to be either discussed, but in some cases just updated or removed.

EO#  Agreed.  If I need to resolve them before making this a WG document please let me know.  I am under the impression that working notes like this are OK in a WG document as long as they're all resolved prior to publication as an RFC.

> 4. Use of Requirements Language should be checked, specifically uses of

EO#  ACK.  I was probably sloppy here and will give it a good scrubbing at next edit.

> helpful (readability) to specifically highlight them in a procedures

EO#  ACK.

> would be helpful to the reader (i.e., why are 32 colors not sufficient

EO#  ACK.  The short answer is that some operators use link colors with global significance (e.g. "This is a link in the northeastern US part of my network") and use this information in their path calculation.  Providing this sort of geotagging information with the existing AGs limits you to 32 regions worldwide.  I'll add something to this effect at the next update.

On the RBNF question from your other email:

---

---

I don't understand this.
rfc3209 uses <SESSION_ATTRIBUTE> but really means "either <SESSION_ATTRIBUTE> or <SESSION_ATTRIBUTE_RA>, as you want".  It does not define SESSION_ATTRIBUTE_RA.

What I'm trying to do in section 3 of my draft is say "you can mix either or both of the _RA types but cannot mix the non-RA SESSION_ATTRIBUTE with the new EXTENDED_SESSION_ATTRIBUTE_RA".  In other words:

<SESSION_ATTRIBUTE>  <---- OK

<SESSION_ATTRIBUTE_RA>   <-------- OK

<SESSION_ATTRIBUTE_RA>
<EXTENDED_SESSION_ATTRIBUTE_RA>     <---- OK

<SESSION_ATTRIBUTE>
<EXTENDED_SESSION_ATTRIBUTE_RA>     <---- NOT OK

and I'd like to do this without having to go through rfc3209 and change all the SESSION_ATTRIBUTE references to say "SESSION_ATTRIBUTE and/or SESSION_ATTRIBUTE_RA" or add "Path_RA Message" rules and all the right wrapper text around it.

Is your comment saying that I can add an additional definition for Path to rfc3209 and say "pick one of these two"?

eric

---

From: Loa Andersson <[email-masked]>
Date: Mon, 03 Jun 2013 15:41:14 +0200

Eric and Dan,

what needs to be resolved - in terms of working notes - is a bit
balancing act. True that some notes are OK, but not to much. I also
depends a bit on the impact the resolution of the notes will have
on the document.

Assuming that we allow some of these notes through when it becomes
a working group document it has t be resolved before we start the
working last call.

Since one of the effects of making a document a working group
document is that the working group takes over the revision control
it might be that an important "TBD" is a reason to make it a
working group document.

/Loa

--

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 3 Jun 2013 15:25:44 +0100

I think Dan is missing a final closing square brace.

That is...

    [ <SESSION_ATTRIBUTE_RA>
        [ <EXTENDED_SESSION_ATTRIBUTE_RA> ] ]

...so that the whole is optional and the EX_RA is only present if _RA is
present.
That could be represented as:

 [ <session_attributes> ]

where

<session_attributes> ::=  <SESSION_ATTRIBUTE_RA> [
<EXTENDED_SESSION_ATTRIBUTE_RA> ]

That is certainly one way of interpreting Eric's text. OTOH, maybe Eric intends
that any of:
- neither
- just _RA
- just EX_RA
- both
...is allowed. If this is the case, then you simply need

    [ <SESSION_ATTRIBUTE_RA> ]
    [ <EXTENDED_SESSION_ATTRIBUTE_RA> ]

By the way, this thread caused me to open the I-D and I can't find motivation
for the protocol extensions in the I-D. At this stage in a document's life I
don't generally mind if the technical details are not all present or even if
they are wrong, but I don't like creating protocol extensions without a clear
motivation. And, yes, I *do* understand that the intention is to create more
attribute colors, but why?

Ciao,
Adrian

> Sent: 03 June 2013 12:28
> Cc: [email-masked]; [email-masked]; draft-osborne-mpls-extended-
> [email-masked]

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Mon, 3 Jun 2013 14:41:43 +0000

Inline

> Adrian Farrel
> Sent: Monday, June 03, 2013 10:26 AM
> To: 'Daniel King'; 'Loa Andersson'; 'Mach Chen'; [email-masked];
> 'Curtis Villamizar'

Ah, OK.  So if I did this:

      <Path Message> ::=       <Common Header> [ <INTEGRITY> ]
                               <SESSION> <RSVP_HOP>
                               <TIME_VALUES>
                               [ <EXPLICIT_ROUTE> ]
                               <LABEL_REQUEST>
                               [ <SESSION_ATTRIBUTE of C-Type 1> ] 
                               | [[SESSION_ATTRIBUTE of C-Type 7] [<EXTENDED_SESSION_ATTRIBUTE_RA>]]

That does what I want.  Can I get away with saying "of C-Type $FOO" in BNF, as I've done here?  My only other choice is to define two different SESSION_ATTRIBUTE strings (say, SESSION_ATTRIBUTE and SESSION_ATTRIBUTE_RA) and use those instead, but that brings me back to having to touch rfc3209 in a bunch of places where I'd have to replace "SESSION_ATTRIBUTE" with "SESSION_ATTRIBUTE or SESSION_ATTRIBUTE_RA".

> attribute colors, but why?

It's in my other reply to Dan, and I'll make sure I add something to the next rev.
---
The short answer is that some operators use link colors with global significance (e.g. "This is a link in the northeastern US part of my network") and use this information in their path calculation.  Providing this sort of geotagging information with the existing AGs limits you to 32 regions worldwide.  I'll add something to this effect at the next update.
---

eric

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 3 Jun 2013 15:53:27 +0100

OK, now I have read Eric's email and am not really comfortable.

The reason why 3209 does not draw a distinction between <SESSION_ATTRIBUTE> and
<SESSION_ATTRIBUTE_RA> is that they are the same object, and any single
occurrence is allowed. So I think your proposal is a bit complicated because you
are saying

> <EXTENDED_SESSION_ATTRIBUTE_RA>     <---- NOT OK

This is hard to express in RNBF because we only deal in objects not in C-Types.

A way to deal with this would be to simply use [ <SESSION_ATTRIBUTE> ... ] and
then use text to say which C-Types are allowed and which not.

However, by re-using the class number you run into a piece of RFC 2205. Viz.
      2.   Unknown C-Type for Known Class
        :
           Generally, the appearance of an object with unknown C-Type
           should result in rejection of the entire message and
           generation of an error message (ResvErr or PathErr as
           appropriate).
This hits backward compatibility. You need to decide whether (for example)
"exclude" should cause a set-up failure by a node that ignores it. Perhaps it
should. Then again, the CNum seems to mean ignore the object if unknown.

My recommendation, along with enhancing the document to include motivation, is
to add text describing clearly what you want to allow and disallow, what
information is carried, and how messages and objects should be handled. The bits
and bytes can wait.

Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 3 Jun 2013 16:03:19 +0100

Hi Eric,

> The short answer is that some operators use link colors with global
significance
> (e.g. "This is a link in the northeastern US part of my network") and use this
> information in their path calculation.  Providing this sort of geotagging
information
> with the existing AGs limits you to 32 regions worldwide.  I'll add something
to
> this effect at the next update.

Thanks for the background.

It makes me wonder whether this use is really resource affinities or a different
pseudo-SRLG-geo-proximity indicator.

Maybe the answer is that you need an entirely new object for an entirely
different application?

Adrian

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Mon, 3 Jun 2013 18:38:42 +0000

> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Monday, June 03, 2013 11:03 AM
> To: Eric Osborne (eosborne); 'Daniel King'; 'Loa Andersson'; 'Mach
> Chen'; [email-masked]; 'Curtis Villamizar'
> Subject: RE: [mpls] MPLS-RT review of draft-osborne-mpls-extended-admin-
> groups-01
> 
> Hi Eric,
> 

A whole new object is overkill, IMO.  What I've describe is how (some) people are already using affinity groups, they just want more of them.

Other uses of affinity groups that I've seen indicate not geolocation but function (PE-P link, satellite link, encrypted link, etc).  I see no reason why this function can't coexist with the geolocation function I've described.

eric

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 4 Jun 2013 04:19:01 +0100

> A whole new object is overkill, IMO.  What I've describe is how (some) people
are
> already using affinity groups, they just want more of them.
> 
> Other uses of affinity groups that I've seen indicate not geolocation but
function
> (PE-P link, satellite link, encrypted link, etc).  I see no reason why this
function
> can't coexist with the geolocation function I've described.

Yeah, people use resource affinities for all sorts of things. It is a rather
convenient container for any number of things (some of them terrible hacks :-).

Well, I'll wait to see your text describing the motivation in the next revision.

A