Subject: [mpls] joint ccamp and mpls working group last call on draft-ietf-mpls-explicit-resource-control-bundle+07

From: Loa Andersson <[email-masked]>
Date: Tue, 01 Jun 2010 09:21:44 +0200

All,

in mid-February the draft-ietf-mpls-explicit-resource-control-bundle
was retruned to the MPLS Working Group from the responsible AD
stating that:

- it had been a long time since the working group last call
- the version that were working group last called was much earlier
   than the one we requested publication for, i.e. the document has
   changed many times since the wg last call
- this document is also of interest for the CCAMP working group, and
   the working group last call should have been jointly between MPLS
   and CCAMP
- there is a need to poll both working group to see if there is
   an interest in this draft.

However it also needs to pointed out that there are at least two deployed
implementations and we need to amke the reservation of the code points
in the IANA section.

This is to start a joint CCAMP and MPLS working group last call on
draft-ietf-mpls-explicit-resource-control-bundle-07.

Please send your comments to the mpls and ccamp working group list.

The joint working group last call ends eob June 16.

/Loa
-- 

Loa Andersson                         email: [email-masked]
Sr Strategy and Standards Manager            [email-masked]
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13

---

From: Loa Andersson <[email-masked]>
Date: Mon, 14 Jun 2010 13:21:43 +0200

Working groups,

we have seen no responses to this last call. The normal
interpretation would be that there are no comments and the
draft is ready to progress. However, because of the special
nature of this working group last call, we won't lightly
subscribe to this interpretation.

The wg last call is therefore extended one week and people
supporting this draft being published as in RFC are encourage
to state this on the list. If you have concerns you are of
course also encourage to state this on the list.

The working group last call will end eob June 25th.

/Loa

--

---

From: Lou Berger <[email-masked]>
Date: Tue, 15 Jun 2010 14:48:18 -0400

> The working group last call will end eob June 25th.

Okay, I've been suitably shamed into doing a full review.

I don't have any fundamental objections to this document.  I think there 
are some editorial fixes and technical clarifications that are needed 
before the document is ready for publication as an RFC.

Here are my LC comments:

- Section 2, 3rd paragraph:  Really should be rewritten.  It's not clear 
what point(s) are being made.

-Section 3.1:
For consistency with 4201:
"component interface identifier" -> "component link identifier"
OLD:
    component link identifier of a (bundled) TE Link. This subobject
NEW:
    component link identifier of a bundled TE Link. This subobject

Section 3.2:
- Section should use normative, RFC2119 language.
- In multiple locations:
   proposal -> document
- Make it clear that processing is occurring at ingress, clarify label 
SO processing:
OLD:
    In most cases, a node initiates recording for a given LSP by adding
    the RRO to the Path message. If the node desires Component Link
    recording and if the outgoing TE link is bundled, then the initial
    RRO contains the Component Link identifier (numbered or unnumbered)
    as selected by the sender. As well, the Component Link Recording
    desired flag is set in the LSP_ATTRIBUTE object. If the node also
    desires label recording, it sets the Label_Recording flag in the
    SESSION_ATTRIBUTE object.

NEW:
    When the ingress node sets the "Component Link Recording desired"
    flag and the outgoing interface is link bundled, then the ingress
    SHOULD create an RRO containing a subobject indicating the
    Component Link identifier (numbered or unnumbered) as selected by
    the sender. When an ingress also desires label recording, it sets
    the Label_Recording flag as defined in [RFC3209].  Any Label Record
    subobjects MUST precede the corresponding component link identifier
    subobject.

- Clarify intent:
OLD
    set is received by an intermediate node, if a new Path message is to
    be sent for a downstream bundled TE link, the node adds a new
    Component Link subobject to the RECORD_ROUTE object (RRO) and appends
    the resulting RRO to the Path message before transmission.
NEW
    set is received by an intermediate node, and the outgoing interface
    is a link bundled, the node SHOULD add

- need to add words on label handling too

- Not sure the following adds anything, but I expect it's talking about 
transmission not reception:
    Note also that, unlike Labels, Component Link identifiers are always
    known on receipt of the Path message.

- the following looks like a bad cut-and-paste from 3209, and needs to 
be reworded.  (BTW what does "needs TE route" mean?)

   When the destination node of an RSVP session receives a Path message
    with an RRO and the "Component Link Recording desired" flag set, this
    indicates that the sender node needs TE route as well as component
    link recording. The destination node initiates the RRO process by
    adding an RRO to Resv messages. The processing mirrors that of the
    Path messages

- Clarify that this following applies to all cases:
OLD:
    The Component Interface Record subobject is pushed onto the
NEW:
    In all cases, a Component Interface Record subobject is pushed onto the

- need to defined label processing in this context:
    When component interfaces are recorded for bi-directional LSPs,
    component interface RRO subobjects for both downstream and upstream
    interfaces MUST be included.

Section 4:

- Why must a component SO follow an SO object with L=0.  To preclude it 
accidentally being an incoming interface?

- "cleared (0)" -> "clear (0)"

- The following has an interesting implication that the ERO always 
contains the component identifiers of the remote side of a TA link:
    local translation into the outgoing interface
    identifier from the received incoming remote interface identifier

Is this correct?  If so, I think this needs to be explicitly stated in 
the format section.  It also counter to how rfc3473 handles label SOs in 
EROs.

- The interactions and implications on label SO processing needs to be 
stated

- The case of a bidirectional LSP with only a component SO with a Ubit = 
0 isn't covered

- "Inferred from above" --> "As implied above"

Section 5.
- first 2 paragraphs use 2119 language for nodes that *don't* support 
the document, i.e., you can't use normative language here.  The 3rd 
paragraph in the section gets it right.

Section 6 seems a bit light.

That's it.

Lou

---

From: Loa Andersson <[email-masked]>
Date: Wed, 30 Jun 2010 11:53:12 +0200

All,

this wg last call has ended.

/Loa

--