Re: [CCAMP] Resolutions of comments on draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext

[[e-mail]]

Hi Pontus

Given the reason that the ASSOCIATION and Extended ASSOCIATION objects 
have already been specified, see RFC4872 and RFC6780, why not just use the 
existing objects ? Futhermore, solution 2 is more generic, and the defined 
LSP identifiers can be used not only for BFD CV configuration, but also 
for other usages by management or control plane.


My2cents

Best regards

Fei :) 



Pontus Sköldström <[e-mail]> 
发件人:  [e-mail]
2012/11/26 23:24

收件人
Lou Berger <[e-mail]>, 
"[e-mail]" 
<[e-mail]>
抄送
CCAMP <[e-mail]>
主题
Re: [CCAMP] Resolutions of comments     on 
draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext






Hi everyone, 

I've resolved all the comments except one, and would like to ask if anyone 
has some good advice regarding that one. 

The problem was pointed out by Fei Zhang in 
http://www.ietf.org/mail-archive/web/ccamp/current/msg13559.html
  "Line 368,  As discussed in the mailinglist when polling the draft 
            
http://tools.ietf.org/html/draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-03
, the tunnel number assigned by the egress 
           LER should be carried back. This issue can be addressed here or 
in that or other document, but I am afraid the current description 
           needs to be changed.  "

The problem is that both MEPs needs to know what values in the MEP-ID 
field of the encapsulated BFD control packet they should expect from the 
other endpoint, so the full MEP-ID of the other side of the connection is 
needed. 
As far as I can see there are two options:

1. Extend the current "Local discriminator" TLV (
http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-10#section-3.3.1
) to include the full MEP-ID. 
The Path message carries the ingress MEP-ID it to the egress, and the 
egress replaces it with its own MEP-ID in the Resv message. 

2. Use the mechanism described in 
http://tools.ietf.org/html/draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-05 
to carry the Tunnel_Num of the egress back to the ingress. 
With this value (carried in the ASSOCIATION object) available, both sides 
can derive what the other sides MEP-ID should be. 

I propose solution #1, since it puts all the information needed for 
configuration in one neat group, and not spread out over multiple RSVP 
object. 
Personally I think solution #2 is bit clumsy since you, as an implementer, 
have to gather information from a bunch of different objects to construct 
the final MEP-ID. 

Any comments? 

Best regards, 

Pontus Sköldström, M.Sc.
Research Scientist
Netlab - Networking and Transmission Laboratory
[phone]
[e-mail]

Acreo AB – Part of Swedish ICT
Electrum 236, 164 40 Kista, Sweden
www.acreo.se
________________________________________
From: [e-mail] [[e-mail]] On Behalf Of Lou 
Berger [[e-mail]]
Sent: Thursday, November 01, 2012 22:28
To: [e-mail]
Cc: CCAMP
Subject: [CCAMP] Resolutions of comments on 
draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext

Authors,
        Can you state how the comments in the following messages have been
addressed in the latest version?

http://www.ietf.org/mail-archive/web/ccamp/current/msg13559.html

http://www.ietf.org/mail-archive/web/ccamp/current/msg13837.html

I also note that no updated version was posted based on the thread
completed in:
http://www.ietf.org/mail-archive/web/ccamp/current/msg14063.html.

Please let us know if you have any open issues you'd like to discuss in
next week's sessions.  We have a couple of cancellations and can fit you
in, if needed.  (And closing on the open issues will help unblock these
documents.)

Much thanks,
Lou
_______________________________________________
CCAMP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ccamp
_______________________________________________
CCAMP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ccamp