Subject: [mpls] WG Last Call on two related WG documents (PathErr and Soft Preemption)

From: Loa Andersson <[email-masked]>
Date: Mon, 18 Feb 2008 17:26:19 +0100

Working Group,

this is to initiate a working group last call on two working group
documents:

"Node behavior upon originating and receiving Resource ReserVation 
Protocol (RSVP) Path Error message"

<draft-ietf-mpls-3209-patherr-02.txt>

and

"MPLS Traffic Engineering Soft Preemption"

<draft-ietf-mpls-soft-preemption-10.txt>

The soft preemption ID became a WG document in Feb 2003. It has been
"on-hold" for a longer period waiting for another ID defining the
term "Hard preemption"; the working group considered that that document
was required to progress the soft preemption document. This document
is the "PathErr-draft" and has now have became a stable WG document.
Therefore it is now possible to start this working group last call.

Please send your comments to the working group mailing list prior to
EOB March 3.

Loa and George

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  [email-masked]
                                            [email-masked]
_______________________________________________
mpls mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/mpls

---

From: Jaudelice de Oliveira <[email-masked]>
Date: Fri, 22 Feb 2008 13:46:10 -0500

I would also like to express my support for both documents... I read  
them both and I think they are ready.

Cheers,
Jau.

Jaudelice C. de Oliveira
Assistant Professor
ECE Dept., Drexel University
http://www.ece.drexel.edu/faculty/deoliveira/

---

From: Lou Berger <[email-masked]>
Date: Tue, 26 Feb 2008 15:13:28 -0500

Here are some comments on draft-ietf-mpls-3209-patherr-02.txt:

- Section 2: "...  the head-end to its tail-end"
   Should use 3209 (ingress/egress) terminology, or 2205's
   (source/destination).  We already have enough terms, not need
   to invent another pair...

- Section 2:
   "The format of the PathErr message as defined in [RFC2205] is as
   follows: ... "

   I think the current text as misleading as it fails to mention that
   the PathErr format (notably <sender descriptor) has been updated
   in subsequent standards track documents (including, 3209).  I think
   it would best to add references to such documents.  Alternatively
   the format should be dropped.

- Section 2.1:
   I think it would be worth adding to this section a discussion that
   parallels section 2.2's discussion of the Path_State_Removed flag.

- Section 2.2:
   I think some guidance on ingress behavior is warranted here,
   e.g. issue PathTear or trigger MBB on receipt of a PathErr.

- Section 3:
   "As defined in [RFC2205], Error Code=12: "Service preempted"
   Given that this document is TE centric, why does this document
   recommend a different code than what is defined in 3209?

---

From: "Attila Takacs" <[email-masked]>
Date: Thu, 28 Feb 2008 16:17:21 +0100

Hi all,
Some minor comments on the two drafts.
Best regards,
Attila

->draft-ietf-mpls-3209-patherr-02:

Section 2: maybe you can remove the PathErr messages format

->draft-ietf-mpls-soft-preemption-10:

Section 6.1 paragraph 2: Reword, hard to follow the message.

Section 7: Regarding interoperability: The text is not clear on how the
Soft Preemption Desired bit in the SESSION_ATTRIBUTE Object is handled.
Is it allowed that an LSR tries to soft preempt an LSP which had not
requested this explicitly by setting the Soft Preemption Desired bit? If
not, than remove the last sentence of the first paragraph: "As a
consequence, the soft preempted TE LSP will not be rerouted with make
before break by the head-end LSR." In any case, it would be useful to
elaborate on this aspect a bit more.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Loa Andersson
> Sent: Monday, February 18, 2008 5:26 PM
> To: [email-masked]
> Cc: Ross Callon; David Ward
> Subject: [mpls] WG Last Call on two related WG documents 
> (PathErr and SoftPreemption)
> 
> Working Group,
> 
> "Node behavior upon originating and receiving Resource 
> ReserVation Protocol (RSVP) Path Error message"
> 
> The soft preemption ID became a WG document in Feb 2003. It 
> has been "on-hold" for a longer period waiting for another ID 
> defining the term "Hard preemption"; the working group 
> considered that that document was required to progress the 
> soft preemption document. This document is the 
> "PathErr-draft" and has now have became a stable WG document.
> Please send your comments to the working group mailing list 
> prior to EOB March 3.
> 
> Loa and George
> 
> 
> 
> 
> 
> 
> --
> Loa Andersson
> 
_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: Lou Berger <[email-masked]>
Date: Fri, 29 Feb 2008 17:50:34 -0500

>Please send your comments to the working group mailing list prior to

I feel a bit like I'm tilting at a windmill raising this at such a 
late date, but - hay - this is part of the reason to have a WG last call.

I think the functional objective of the draft, i.e., being able to 
remotely request/trigger make-before-break, is very important but 
have a real concern about the specified mechanism.  Specifically it 
seems to me that triggering ingress behavior (MBB) based on RRO flags 
is a pretty MAJOR departure from intended/typical RRO usage and the 
RSVP object transaction model.

Also, and probably more significantly, I know this draft has been 
around for a *really* long, but in the interim RFC4920 has been 
published as a Standards Track document and it too supports the 
ability to trigger "End-to-end Re-routing".  This seems to exactly 
duplicate the function of soft-preemption.  Having two ways to do the 
same thing is usually considered a bad thing.  While fairly painful, 
perhaps the best thing would be for the WG to either:
(a) ask for the current document to revised to leverage 4920
     mechanisms, or
(b) change the Intended status of this draft to informational

Again, I know either will be painful for the Author's of the draft, 
but I think either is less painful from an overall 
standards/technology standpoint.

Independent of the above, I have some other comments on the draft (in 
its current form):

1. There are other sources of soft preemption (aka remote MBB
    request), e.g., graceful shutdown, and they should be allowed
    under document.  I believe this only impacts narrative text.

2. There's no general discussion on how/when RROs are added, e.g.,
    what to do when the incoming message doesn't include an RRO.

3. The draft should address the case were the presence/insertion of
    the RRO results in a message being too large. (which may occur at
    an upstream or downstream node.)

4. The draft should address handling of RRO when crossing domain
    boundaries.

That's it for now...

Lou