RE: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt

[Rahul Aggarwal <rahul@juniper.net>]

Hi Ben,

Thanks for the comments. Please see inline:

On Mon, 15 May 2006 benjamin.niven-jenkins@bt.com wrote:

> owner-ccamp@ops.ietf.org <> wrote:
> > 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.
>
> Section 4.3, paragraph 1 states "The two most notable differences are
> that a P2MP LSP comprises multiple S2L Sub-LSPs and that, as a result of
> this, it may not be possible to represent full state in a single IP
> packet and even more likely that it can't fit into a single IP packet."
>
> Which appears to repeat itself.
>

Will reword the following:

"As with all other RSVP controlled LSPs, P2MP LSP state is managed
   using RSVP messages. While use of RSVP messages is the same, P2MP LSP
   state differs from P2P LSP state in a number of ways. The two most
   notable differences are that a P2MP LSP comprises multiple S2L Sub-
   LSPs and that, as a result of this, it may not be possible to
   represent full state in a single IP packet and even more likely that
   it can't fit into a single IP packet. It must also be possible to
   efficiently add and remove endpoints to and from P2MP TE LSPs. An
   additional issue is that the P2MP LSP must also handle the state
   "remerge" problem, see [RFC4461]."

to

"As with all other RSVP controlled LSPs, P2MP LSP state is managed
   using RSVP messages. While use of RSVP messages is the same, P2MP LSP
   state differs from P2P LSP state in a number of ways. A P2MP LSP
comprises multiple S2L Sub-LSPs and as a result of this it may not be
possible to represent full state in a single IP packet. It must also be
possible to efficiently add and remove endpoints to and from P2MP TE LSPs. An
additional issue is that the P2MP LSP must also handle the state
"remerge" problem, see [RFC4461]."



> Section 5.2.4, paragraph 2 states "The ingress LSP may request 'LSP
> integrity' by setting bit (TBA) of the Attributes Flags TLV. The bit is
> set if LSP integrity is required."
>
> Should the bit that needs setting be defined here (rather than TBA) or
> is that down to IANA?
>

The editors will request a specific bit.

> Section 18, paragraph 1 "This section is currently under discussion
> between the authors and will be updated in the next revision."
>
> Is this paragraph appropriate?
>

No. Thanks for catching it. Will remove it.

Thanks,
rahul

> Ben
>
>