Subject: Re: [mpls] TR: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt

From: Rahul Aggarwal <[email-masked]>
Date: Tue, 20 Jun 2006 13:46:31 -0700 (PDT)

Hi JL,

Sorry for the delay. Please see below:

On Fri, 26 May 2006, LE ROUX Jean-Louis RD-CORE-LAN wrote:

> Hi all,
>
> I transfer the below comments on this list,
> as it should be discussed as part of last call comments.
>
> Regards,
>
> JL
>
> > -----Message d'origine-----
> > De : LE ROUX Jean-Louis RD-CORE-LAN
> > Envoyé : jeudi 25 mai 2006 14:19
> > À:
> > Objet : RE: working group last call on
> > draft-ietf-mpls-rsvp-te-p2mp-05.txt
> >
> > Hi Rahul, Dimitri, Seisho
> >
> > Thanks for the great edit job,
> >
> > Find below a set of comments on this revision 05
> >
> > Four technical points:
> >
> > 1: Section 8.1.2 Downstream notification
> >
> > The text in 8.1.2 is a bit unclear
> >
> > "A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC
> >    object(s) of a Resv message to the value, that was received in the
> >    corresponding Path message. If the incoming Resv message carries a
> >    Notify Request object then, the LSR MUST set the Notify
> > node address
> >    in the Notify Request object to the value, that was received in the
> >    corresponding Path message",
> >

> > Which value? The sub-group originator? the notify address?

This should be the Router ID of the transit LSR if the transit LSR is
merging more than one Resv with a Notify Request object.

> > This is unclear.  The processing needs to be clarified.
> > We could update as follows:
> >
> > "If the incoming Resv message carries a Notify Request object then,
> > 		-If the sub-group originator ID is its own
> > address, the LSR MUST set the Notify node address in the
> > Notify Request object to its own address, in the Resv message
> > that it sends upstream.
> > 	    -If the sub group originator ID is not its own
> > address, the LSR MUST propagate the Notify Request object
> > unchanged, in the Resv message that it sends upstream."
> >

Shouldn't the transit LSR always set its own address in the Notify Request
if it is merging multiple Resvs with Notify Request objects into a single
Resv ? The current text is not clear on this either.

How about:

"A transit LSR sets the Sub-Group Originator ID in the
FILTER_SPEC object(s) of a Resv message to the value, that was received in
the corresponding Path message. If the incoming Resv message carries a
Notify Request object then:

 - If there is at least another incoming Resv message that carries a
Notify Request object and the LSR merges these Resv messages into a single
Resv message that is sent upstream, the LSR MUST set the Notify
node address in the Notify Request object to its Router ID.

- Else the LSR MUST propagate the Notify Request object
unchanged, in the Resv message that it sends upstream."

> > 2: Section 8.2 ResvConf
> >
> > Similar comment
> >
> > "A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC
> >    object(s) of a Resv message to the value, that was received in the
> >    corresponding Path message. If any of the incoming Resv messages
> >    corresponding to a single Path message carry a RESV_CONFIRM object
> >    then the LSR MUST include a RESV_CONFIRM object in the
> > corresponding
> >    Resv message that it sends upstream and MUST set the
> > receiver address
> >    in the RESV_CONFIRM object to the value that was received in the
> >    corresponding Resv message."
> >
> > Change to
> >
> > "
> >    A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC
> >    object(s) of a Resv message to the value, that was received in the
> >    corresponding Path message. If any of the incoming Resv messages
> >    corresponding to a single Path message carry a RESV_CONFIRM object
> >    then the LSR MUST include a RESV_CONFIRM object in the
> > corresponding
> >    Resv message that it sends upstream. If the sub-group
> > originator ID is its own address then
> >    it MUST set the receiver address in the RESV_CONFIRM
> > object to this addresse, else it MUST
> >    propagate the object unchanged"
> >

Shouldn't the transit LSR always set its own address in the RESV_CONFIRM
if it is merging multiple Resvs with RESV_CONFIRM objects into a single
Resv ? The current text is not clear on this either.

How about:

"A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC
object(s) of a Resv message to the value that was received in the
corresponding Path message. If an incoming Resv message
corresponding to a single Path message carries a RESV_CONFIRM object
then the LSR MUST include a RESV_CONFIRM object in the corresponding
Resv message that it sends upstream and:

 - If there is at least another incoming Resv message that carries a
RESV_CONFIRM object and the LSR merges these Resv messages into a single
Resv message that is sent upstream, the LSR MUST set the receiver
address in the RESV_CONFIRM object to its Router ID.

- Else the LSR MUST propagate the RESV_CONFIRM object
unchanged, in the Resv message that it sends upstream."

> >
> > 3: Section 14.2 Sub-group based reoptimization
> >
> > The new path may intersect the old path, this is a case of
> > rerouting and this is not covered by remerge procedures as
> > described in section 18. Hence Transient Data duplication may
> > occur during the time between the Resv is received and the
> > PathTear is sent. To avoid data duplication the branch node
> > must not start transmitting on the new path before the old
> > path has been torn down, but this will lead to transient packet loss.
> > This should be clearly mentionned here IMO.
> > Actually the only way to avoid both transient duplication and
> > transient packet loss is to rely on the global mb4b procedure
> > with a new LSP id...
> >

How about adding the following to this section:

"Sub-Group based re-optimization may result in transient data duplication
as the new Path messages for a set of S2L sub-LSPs may transit one or more
nodes with the old Path state for the same set of S2L sub-LSPs. "

> > 4: Section 18.1.1 Remerge Procedure
> >
> > The text says
> >    "The PathErr message MUST include all of the objects
> >    normally included in a PathErr message, as well as one or more SUB-
> >    LSP objects from the set of sub-LSPs associated with the matching
> >    P2MP LSP Path state.  A minimum of three SUB-LSP objects is
> >    RECOMMENDED. This will allow the node that caused the re-merge to
> >    identify the outgoing Path state associated with the valid
> > portion of
> >    the P2MP LSP. The set of SUB-LSP objects in the received
> > Path message
> >    MUST also be included"
> >
> > And then:
> >
> >    "A node that receives a PathErr message that contains the
> > Error Value
> >    "Routing Problem/P2MP Remerge Detected" MUST determine if it is the
> >    node that created the re-merge case.  This is done by checking
> >    whether there is any intersection between the set of
> > SUB-LSP objects
> >    associated with the matching P2MP LSP Path state and the
> > set of SUB-
> >    LSP objects in the received PathErr message.  If there is, then the
> >    node created the re-merge case."
> >
> > There is an issue here. Actually there will always be an
> > intersection, because the PathErr includes the set of sub-lsp
> > objects in the received Path... IMO for this procedure to work
> > the PathErr MUST only include sub-LSP objects associated with
> > the matching P2MP LSP state on the rermerge LSR and must not
> > include the set of SUB-LSP objects in the received Path message.
> > By the way why are three objects recommended?
> >

I believe this was clarified by John Drake offline and no revisions were
needed ?

> >
> > Also find below some minor edits:
> >
> > Section 6.1
> >
> > <S2L sub-LSP descriptor> ::= <S2L_SUB_LSP&>; [ <P2MP
> >    SECONDARY_EXPLICIT_ROUTE> ]
> > Change to:
> > <S2L sub-LSP descriptor> ::= <S2L_SUB_LSP&>; [ <P2MP
> >    SECONDARY_RECORD_ROUTE> ]
> >

Ok.

> > Section 7.1
> > <S2L sub-LSP list> change to <S2L sub-LSP descriptor list>
> >

Ok.

> > Section 8.1.2
> >
> >  "If this LSR subsequently receives a corresponding Notify
> > message from
> >    an upstream LSR than it MUST:
> >    - send a Notify message downstream toward the Notify
> >      node address that the LSR received in the Resv message.
> >    - process the sub-group fields of the FILTER_SPEC object in the
> >      received Notify message, and modify their values in the Notify
> >      message that is forwarded to match the sub-group field values
> >      in the original Path message sent downstream by this LSR."
> >
> > Invert these two bullets
> >

Ok.

> > Section 8.2
> >
> > "If this LSR subsequently receives a corresponding ResvConf message
> >    from an upstream LSR then it MUST:
> >    - send a ResvConf message downstream toward the receiver
> > address that
> >      the LSR received in the RESV_CONFIRM object in the Resv message.
> >    - process the sub-group fields of the FILTER_SPEC object in the
> >      received ResvConf message, and modify their values in
> > the ResvConf
> >      message that is forwarded to match the sub-group field values
> >      in the original Path message sent downstream by this LSR."
> >
> > Invert these two bullets
> >

Ok.

> > Section 11.2 last sentence
> >
> >    "Note the receiver of a ResvErr message is able to
> > identify the errored outgoing Path [Change to: Resv]
> >    message, and outgoing interface, based on the Sub-Group fields
> >    received in the ResvErr message.
>

Ok.

>
> > Section 13
> >
> >  "A sender on a LAN uses a different label for sending traffic to each
> >    node on the LAN that belongs to the P2MP LSP"
> >
> > This is not always the case, I would rather say
> >
> > "Downstream nodes for a given P2MP LSP on a LAN are likely to
> > allocate a different label, in which case the sender has to
> > perform replication"...
> >

Actually the procedures in this document imply that a sender on a LAN must
do replication if there is more than one downstream receiver. Upstream
labels are required to avoid this.

However I do realize that the first sentence is not entirely accurate. How
about:

"If there are multiple downstream LSRs on a LAN on a P2MP LSP, a sender
LSR on the LAN has to perform replication. A separate copy of the data
is unicast to each of the downstream LSRs"

> > Section 16
> >
> >    "Stitching and nesting
> >    considerations and procedures are described further in [INT-REG]."
> >
> > Change to "Stitching and nesting
> >    considerations and procedures are described further in
> > [LSP-STITCH] and [RFC4206]."
> >
> > Section 17
> >
> > Infact => In fact
> >

Ok.

> > Section 19.4.2 P2MP LSP_IPv4 FILTER_SPEC Object => P2MP
> > LSP_IPv6 FILTER_SPEC object
> >

Ok.

> > Also some references need to be updated...
> >

Will do that.

Thanks for the detailed comments.

rahul

> > Best Regards,
> >
> > JL
> >
> > > -----Message d'origine-----
> > > De : [email-masked]
> > > [mailto:[email-masked]] De la part de Loa
> > Andersson Envoyé :
> > > samedi 13 mai 2006 12:48 À : [email-masked] Cc : ccamp;
> > George Swallow;
> > > [email-masked]; Deborah Brungard; Ross Callon; Bill Fenner
> > > Objet : working group last call on
> > draft-ietf-mpls-rsvp-te-p2mp-05.txt
> > >
> > > Working Group,
> > >
> > > this initiates a two week working group last call on
> > > draft-ietf-mpls-rsvp-te-p2mp-05.txt
> > >
> > > please send comments to the MPLS working group mailling list and/or
> > > working co-chairs.
> > >
> > > The last call ends eob May 28th.
> > >
> > > The ccamp mailing list copied as this is a work that has an overlap
> > > between the working groups.
> > >
> > > 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]
> https://www1.ietf.org/mailman/listinfo/mpls
>
>

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

---

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Thu, 22 Jun 2006 15:40:36 +0200

Hi Rahul,

Your proposed text for the processing of Notify Request and Resv Conf objects covers my points.

Thanks, 

JL

> De : Rahul Aggarwal [mailto:[email-masked]] 
> Envoyé : jeudi 22 juin 2006 15:35
> À : LE ROUX Jean-Louis RD-CORE-LAN
> Cc : [email-masked]
> Objet : RE: [mpls] TR: working group last call on 
> Please see below:
> On Thu, 22 Jun 2006, LE ROUX Jean-Louis RD-CORE-LAN wrote:
> 
> > Hi Rahul,
> >
> > Please see inline,
> >
> >
> > > De : Rahul Aggarwal [mailto:[email-masked]] Envoyé : mardi 20 
> > > juin 2006 22:47 À : LE ROUX Jean-Louis RD-CORE-LAN Cc : 
> > > [email-masked] Objet : Re: [mpls] TR: working group last call on 
> > > > I transfer the below comments on this list, as it should be
> > > discussed
> > > > as part of last call comments.
> > > >
> > > > Regards,
> > > >
> > > > JL
> > > >
> > > > > De : LE ROUX Jean-Louis RD-CORE-LAN Envoyé : jeudi 25 
> mai 2006 
> > > > > 14:19
> > > > > À:
> > > > >    Notify Request object then, the LSR MUST set the 
> Notify node 
> > > > > address
> > > This should be the Router ID of the transit LSR if the 
> transit LSR 
> > > is merging more than one Resv with a Notify Request object.
> >
> > Ok, but it also applies when the LSR changes the sub-group 
> originator 
> >id to its own address doesn't it?
> >
> 
> Yes, you are right.
> 
> > >
> > > address, the LSR MUST
> > > > > set the Notify node address in the Notify Request object
> > > to its own
> > > > > address, in the Resv message that it sends upstream.
> > > address, the LSR
> > > > > MUST propagate the Notify Request object unchanged, 
> in the Resv 
> > > > > message that it sends upstream."
> > > > >
> > >
> > > Shouldn't the transit LSR always set its own address in 
> the Notify 
> > > Request if it is merging multiple Resvs with Notify 
> Request objects 
> > > into a single Resv ? The current text is not clear on this either.
> >
> > A transit LSR should actually put its own address in the Notify 
> > Request not only when it is merging multiple Resv, but also when it 
> > changes the sub-group orignator id to its own address (even 
> if there 
> > is no Resv merging)
> >
> > >
> > > How about:
> > >
> FILTER_SPEC 
> > > Notify Request object and the LSR merges these Resv 
> messages into a 
> > > single Resv message that is sent upstream, the LSR MUST set the 
> > > Notify node address in the Notify Request object to its Router ID.
> > >
> unchanged, 
> > > in the Resv message that it sends upstream."
> >
> > See above comment
> >
> 
> How about adding a bullet between these two bullets:
> 
> "- Else if the LSR sets the Sub-Group Originator ID in the 
> outgoing Path message, that corresponds to the received Resv 
> message, to its own address, the LSR MUST set the Notify node 
> address in the Notify Request object to its Router ID."
> 
> 
> 
> > >
> > >
> > > > > 2: Section 8.2 ResvConf
> > > > >
> > > > > Similar comment
> > > > >
> > > > >    Resv message that it sends upstream and MUST set 
> the receiver 
> > > > > address
> > > > >    it MUST set the receiver address in the 
> RESV_CONFIRM object 
> > > > > to this addresse, else it MUST
> > > Shouldn't the transit LSR always set its own address in the 
> > > RESV_CONFIRM if it is merging multiple Resvs with RESV_CONFIRM 
> > > objects into a single Resv ? The current text is not 
> clear on this 
> > > either.
> >
> > Same comment. Yes but IMO it should also do it when it changes the 
> > sub-group originator id (even with no Resv merge)?
> >
> 
> That is correct.
> 
> > >
> > > How about:
> > >
> > > RESV_CONFIRM object and the LSR merges these Resv messages into a 
> > > single Resv message that is sent upstream, the LSR MUST set the 
> > > receiver address in the RESV_CONFIRM object to its Router ID.
> > >
> unchanged, in 
> > > the Resv message that it sends upstream."
> > >
> >
> > This also applies when the LSR changes the sub-group originator id 
> > without any Resv merge
> >
> 
> How about adding a bullet in between these two bullets:
> 
> "- If the LSR sets the Sub-Group Originator ID in the 
> outgoing Path message, that corresponds to the received Resv 
> message, to its own address, the LSR MUST set the receiver 
> address in the RESV_CONFIRM object to its Router ID."
> 
> thanks,
> rahul
> 
> > >
> > > > >
> > > > > The new path may intersect the old path, this is a case
> > > of rerouting
> > > > > and this is not covered by remerge procedures as described in 
> > > > > section 18. Hence Transient Data duplication may occur during 
> > > > > the time between the Resv is received and the PathTear is
> > > sent. To avoid
> > > > > data duplication the branch node must not start
> > > transmitting on the
> > > > > new path before the old path has been torn down, but this
> > > will lead
> > > > > to transient packet loss.
> > > > > transient packet loss is to rely on the global mb4b
> > > procedure with a
> > > > > new LSP id...
> > > > >
> > >
> > > "Sub-Group based re-optimization may result in transient data 
> > > duplication as the new Path messages for a set of S2L 
> sub-LSPs may 
> > > transit one or more nodes with the old Path state for the 
> same set 
> > > of S2L sub-LSPs. "
> >
> > The proposed text addresses my point and is fine with me
> >
> > >
> > >
> > > > >    the P2MP LSP. The set of SUB-LSP objects in the 
> received Path 
> > > > > message
> > > > >    MUST also be included"
> > > > >
> > > > > And then:
> > > > >
> > > > >    "A node that receives a PathErr message that contains
> > > the Error
> > > > > Value
> > > > >    whether there is any intersection between the set 
> of SUB-LSP 
> > > > > objects
> > > > >    associated with the matching P2MP LSP Path state and
> > > the set of
> > > > > SUB-
> > > > > objects in the received Path... IMO for this procedure to
> > > work the
> > > > > PathErr MUST only include sub-LSP objects associated with the 
> > > > > matching P2MP LSP state on the rermerge LSR and must not
> > > include the
> > > > > set of SUB-LSP objects in the received Path message.
> > > I believe this was clarified by John Drake offline and no 
> revisions 
> > > were needed ?
> >
> > I will provide more comments in a following email.
> >
> > Best Regards,
> >
> > JL
> >
> > >
> > > > >
> > > > >  "If this LSR subsequently receives a corresponding
> > > Notify message
> > > > > from
> > > > >    - send a ResvConf message downstream toward the
> > > receiver address
> > > > > that
> > > > >      received ResvConf message, and modify their 
> values in the 
> > > > > ResvConf
> > > > > allocate a different label, in which case the sender has
> > > to perform
> > > > > replication"...
> > > > >
> > >
> > > Actually the procedures in this document imply that a sender on a 
> > > LAN must do replication if there is more than one downstream 
> > > receiver. Upstream labels are required to avoid this.
> > >
> > > "If there are multiple downstream LSRs on a LAN on a P2MP LSP, a 
> > > sender LSR on the LAN has to perform replication. A 
> separate copy of 
> > > the data is unicast to each of the downstream LSRs"
> > >
> > >
> > > > > Section 16
> > > > >
> > > > >    "Stitching and nesting
> > > [INT-REG]."
> > > > > > [email-masked]; Deborah Brungard; Ross 
> Callon; Bill 
> > > > > > Fenner Objet : working group last call on
> > > > > > please send comments to the MPLS working group 
> mailling list 
> > > > > > and/or working co-chairs.
> > > > > >
> > > > > > The ccamp mailing list copied as this is a work that has an 
> > > > > > overlap between the working groups.
> > > > > >
> > > > > > Loa and George
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Loa Andersson
> > > > > >

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 26 Jun 2006 18:53:14 -0700

Zafar,

[clipped...]

> Yakov, Adrian, et al
> 
> I think global scoping will be a bad idea. Furthermore, we cannot force
> it to come from multicast IP address space. So Ingress node scoping is
> quite obvious and IMHO suffices. 

Agreed. What I am asking is to explicitly spell this out in the document
(see the e-mail I sent today).
  
Yakov.