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

["Eric Osborne (eosborne)" <[e-mail]>]

Hi Daniel-

  Thanks for your comments.  My replies are inline.

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Daniel King
> Sent: Monday, June 03, 2013 6:13 AM
> To: 'Loa Andersson'; 'Mach Chen'; [e-mail]; 'Curtis
> Villamizar'
> Cc: [e-mail]; [e-mail]; draft-osborne-mpls-
> [e-mail]
> Subject: Re: [mpls] MPLS-RT review of draft-osborne-mpls-extended-admin-
> groups-01
> 
> 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).
> 


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.

> 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.

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.


> 
> 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.
> 

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
> "must", "shouldn't".
> 

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

> 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.
> 

EO#  ACK.

> 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?).

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:

---
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> ]
---

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


> 
> Br, Dan.
> 
> -----Original Message-----
> From: Loa Andersson [mailto:[e-mail]]
> Sent: 18 May 2013 19:51
> To: Daniel King; Mach Chen; [e-mail]; Curtis Villamizar
> Cc: [e-mail];
> [e-mail]; 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: [e-mail]
> Senior MPLS Expert                          [e-mail]
> Huawei Technologies (consultant)     phone: [phone]
> 
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls